LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 08-22-2007, 11:51 PM   #1
jakykong
Member
 
Registered: Apr 2006
Location: Washington
Distribution: Debian Gnu/Linux Lenny on AMD64x2 (32-bit mode), an AMD Sempron 64 laptop, debian, 32bit
Posts: 101

Rep: Reputation: 15
gdb won't recognize a.out file format


Greetings!

Before you ask, Yes, I compiled with the -g option. That didn't fit in the title.

I am running a Debian Gnu/Linux system, AMD64, using g++ 4.1.2 and gdb 6.4.90.

I'm writing a class I call evector (it's an implementation of a vector, optimized for large amounts of data, or at least I hope so ). I have 2 files, evector.h (containing the declarations and definitions for the evector template), and test.cpp, a simple program to test the evector.

Evector is producing a segmentation fault (unusual for C++, but probably because I'm fiddling with manual memory allocation). I'd like to investigate. So I went to gdb (for the first time, actually). I read through the manual (at least through most of it), and so did this:

$ g++ -g test.cpp
$ #test.cpp happens to include evector and instantiate it with int.
$ gdb
(gdb) file a.out
BFD: /home/jakykong/projects/evector/a.out: don't know how to handle OS specific section `.gnu.hash' [0x6ffffff6]
"/home/jakykong/projects/evector/a.out": not in executable format: File format not recognized
(gdb)

Does anyone know what might be causing this error and/or how to fix it?

Thanks!
 
Old 08-23-2007, 01:39 AM   #2
bgoodr
Member
 
Registered: Dec 2006
Location: Oregon
Distribution: RHEL[45] {x86,x86_64}, Debian "testing" {x86,x86_64}
Posts: 219

Rep: Reputation: 36
Hi jakykong,

That seems like a very odd message. Have you tried compiling and GDB'ing a straight ::main() function under g++ that just simply calls :rintf() and returns 0? I'm thinking there is something going on that does not involve your specific code, that might be fouling up GDB.

Have you verified that the version of GDB is working for that version of GCC? I don't know for sure, but there may be some issues with using a version of GDB that doesn't mate well with older versions of GCC, and vice versa.

Disclaimer: I'm not a Debian user, but have some scars from using GCC on RHEL and Fedora, so this may be a Debian-specific problem that I'm not qualified to help with.

Barring that, have you turned on -Wall and -Werror and extricated all warnings in your code?

Thanks,
bgoodr
 
Old 08-23-2007, 01:46 AM   #3
jakykong
Member
 
Registered: Apr 2006
Location: Washington
Distribution: Debian Gnu/Linux Lenny on AMD64x2 (32-bit mode), an AMD Sempron 64 laptop, debian, 32bit
Posts: 101

Original Poster
Rep: Reputation: 15
I created a simple file with these contents:

#include <iostream>

int main()
{
std::cout << "This is a Test." << std::endl;
}

Compiled it with -Wall, -Werror, and -g. Gdb still gives me the same error message.


I thought about the versions being a problem, but there are 2 things going through my mind (this doesn't mean it can't be the case, it's just thoughts). First, since a.out format is standard, different versions of gdb really shouldn't depend on specific versions of g++/gcc to at least get basic functionality. Second, assuming the version *is* the problem, why doesn't gdb give a message saying something along the lines of "unsupported version" instead of "unsupported format"?

Also, and probably more importantly, I really have no idea where to look for what versions work with each other
 
Old 08-23-2007, 02:16 AM   #4
bgoodr
Member
 
Registered: Dec 2006
Location: Oregon
Distribution: RHEL[45] {x86,x86_64}, Debian "testing" {x86,x86_64}
Posts: 219

Rep: Reputation: 36
Quote:
Originally Posted by jakykong View Post
Also, and probably more importantly, I really have no idea where to look for what versions work with each other
Good point. I don't know either about how to tell which GDB mates well with which version GCC. That is probably is a weak point either in how GDB or GCC, or both, are documented (or it is documented in the code and not in the manuals, or, or, or...). Does the resulting executable run outside of GDB?

Not that this could help in any way, run the file command on the resulting a.out. What does the output say?

Also, have you successfully compiled other programs with this GCC and were you able to run GDB on the result? Is this the GDB that comes installed with the version of Debian, or is it something that is built from source?

BTW, I have a AMD64 system, which is Fedora 7, but not Debian. I've verified that I can build a simple C++ program (using c++ and not g++, but I doubt that matters). Here are the results:

Code:
bash-3.2$ test.exe
test.cxx:11: BEGIN
test.cxx:15: END
bash-3.2$ gdb test.exe
GNU gdb Red Hat Linux (6.6-15.fc7rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) b main
Breakpoint 1 at 0x40095b: file test.cxx, line 11.
(gdb) r
Starting program: /home/brentg/tmp2/test.exe 

Breakpoint 1, main (argc=1, argv=0x7fff82358228) at test.cxx:11
11        std::cout << __FILE__ << ":" << __LINE__ << ": BEGIN" << std::endl;
(gdb) l
6    
7    
8    int
9    main (int argc, char *argv[])
10    {
11        std::cout << __FILE__ << ":" << __LINE__ << ": BEGIN" << std::endl;
12    
13    //     printf("got here\n"); fflush(stdout);
14    
15        std::cout << __FILE__ << ":" << __LINE__ << ": END" << std::endl;
(gdb) n
test.cxx:11: BEGIN
15        std::cout << __FILE__ << ":" << __LINE__ << ": END" << std::endl;
(gdb) c
Continuing.
test.cxx:15: END

Program exited normally.
(gdb) quit
bash-3.2$ file test.exe
test.exe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
bash-3.2$ cat test.cxx
// -*-mode: c++; indent-tabs-mode: nil; -*-

#include <iostream>
// // using namespace std;
// #include <stdio.h>


int
main (int argc, char *argv[])
{
    std::cout << __FILE__ << ":" << __LINE__ << ": BEGIN" << std::endl;

//     printf("got here\n"); fflush(stdout);

    std::cout << __FILE__ << ":" << __LINE__ << ": END" << std::endl;

    return(0);

} // end main()

bash-3.2$
bgoodr
 
Old 08-23-2007, 02:22 AM   #5
bgoodr
Member
 
Registered: Dec 2006
Location: Oregon
Distribution: RHEL[45] {x86,x86_64}, Debian "testing" {x86,x86_64}
Posts: 219

Rep: Reputation: 36
Also, since we are considering that versions of GCC and GDB are perhaps not working well together, here are my versions as of right now:

Code:
bash-3.2$ which gcc
/usr/bin/gcc
bash-3.2$ gcc --version
gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bash-3.2$ which c++
/usr/bin/c++
bash-3.2$ c++ --version
c++ (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bash-3.2$ which gdb
/usr/bin/gdb
bash-3.2$ gdb --version
GNU gdb Red Hat Linux (6.6-15.fc7rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
bash-3.2$
Again, this is on a Fedora 7 system, which you do not have, but this is what worked for me.

Hmmm, the version of GDB you have is 6.4.90, whereas the version I have is 6.6-15.fc7rh (the fc7rh part of that I believe is a nomenclature used by Fedora and/or Red Hat). It's probably a long shot, but I wonder if you would get better results if you pulled GDB version 6.6.x down, compiled it, and tried it instead of the version you have.

bgoodr
 
Old 08-23-2007, 12:47 PM   #6
jakykong
Member
 
Registered: Apr 2006
Location: Washington
Distribution: Debian Gnu/Linux Lenny on AMD64x2 (32-bit mode), an AMD Sempron 64 laptop, debian, 32bit
Posts: 101

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by bgoodr View Post
Good point. I don't know either about how to tell which GDB mates well with which version GCC. That is probably is a weak point either in how GDB or GCC, or both, are documented (or it is documented in the code and not in the manuals, or, or, or...). Does the resulting executable run outside of GDB?

Not that this could help in any way, run the file command on the resulting a.out. What does the output say?

Also, have you successfully compiled other programs with this GCC and were you able to run GDB on the result? Is this the GDB that comes installed with the version of Debian, or is it something that is built from source?

BTW, I have a AMD64 system, which is Fedora 7, but not Debian. I've verified that I can build a simple C++ program (using c++ and not g++, but I doubt that matters). Here are the results:

{snip}

bgoodr
The resulting test executable from my second post works fine, outside of gdb.

I haven't used gdb before at all, but i'll write a C program and see if gcc can create a debuggable code.

All of this is what comes with debian (it's in the repositories). Since debian is supported intirely by it's volunteer developers, I would expect a matching pair of versions to be selected all the time, but maybe this is an overstatement? No reason I can't grab sources if nothing else works, but I'll admit that debian's packaging system is much more convenient .

c++ is symlinked to g++ on my system.
 
Old 08-23-2007, 12:52 PM   #7
jakykong
Member
 
Registered: Apr 2006
Location: Washington
Distribution: Debian Gnu/Linux Lenny on AMD64x2 (32-bit mode), an AMD Sempron 64 laptop, debian, 32bit
Posts: 101

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by bgoodr View Post
Also, since we are considering that versions of GCC and GDB are perhaps not working well together, here are my versions as of right now:

{snip}

Again, this is on a Fedora 7 system, which you do not have, but this is what worked for me.

Hmmm, the version of GDB you have is 6.4.90, whereas the version I have is 6.6-15.fc7rh (the fc7rh part of that I believe is a nomenclature used by Fedora and/or Red Hat). It's probably a long shot, but I wonder if you would get better results if you pulled GDB version 6.6.x down, compiled it, and tried it instead of the version you have.

bgoodr
the fc7rh is a nomenclature. Debian uses them too, sometimes. Depends if modifications have been made to the sources (which means a reversioning) or not (which means the version is left alone). That my version has no such tag on either g++ or gdb means no changes were made to the source. (at least, that's Debian's way of naming things, I can't say I totally know fedora's policy, but I assume it's similar)

Is it possible that the 6.4 vs 6.6 made enough difference to mess things up? I'll go try my plain C program to test that (gcc hasn't been updated as recently an g++, according to my package manager).

EDIT:
I just tried the C program. gdb does the same exact thing on a C program as a C++ program (they're not compiled with the same program). Therefore, I'm going to download the latest gdb sources.

Last edited by jakykong; 08-23-2007 at 12:56 PM. Reason: why create 2 posts where one will do?
 
Old 08-23-2007, 10:21 PM   #8
bgoodr
Member
 
Registered: Dec 2006
Location: Oregon
Distribution: RHEL[45] {x86,x86_64}, Debian "testing" {x86,x86_64}
Posts: 219

Rep: Reputation: 36
I'm wondering now about the a.out file format. What does the "file" command show when you run it on the a.out file? Compare that with the output of the "file" command on /usr/bin/ls. Are they the same format?

bgoodr
 
Old 08-23-2007, 10:43 PM   #9
bgoodr
Member
 
Registered: Dec 2006
Location: Oregon
Distribution: RHEL[45] {x86,x86_64}, Debian "testing" {x86,x86_64}
Posts: 219

Rep: Reputation: 36
Also, a quick search on Google for "gnu.hash" returned a number of hits. One is:: http://code.linuxonly.nl/code/gnuhash.html

Check it out. Sounds like some GCC default got fouled up perhaps.

bgoodr
 
Old 08-24-2007, 12:17 AM   #10
jakykong
Member
 
Registered: Apr 2006
Location: Washington
Distribution: Debian Gnu/Linux Lenny on AMD64x2 (32-bit mode), an AMD Sempron 64 laptop, debian, 32bit
Posts: 101

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by bgoodr View Post
I'm wondering now about the a.out file format. What does the "file" command show when you run it on the a.out file? Compare that with the output of the "file" command on /usr/bin/ls. Are they the same format?

bgoodr
They're both 64-bit ELF binaries, the a.out is not stripped, /bin/ls is stripped (by the way, ls is never in /usr )

Aside from that difference, they're the same.
 
Old 08-24-2007, 12:20 AM   #11
jakykong
Member
 
Registered: Apr 2006
Location: Washington
Distribution: Debian Gnu/Linux Lenny on AMD64x2 (32-bit mode), an AMD Sempron 64 laptop, debian, 32bit
Posts: 101

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by bgoodr View Post
Also, a quick search on Google for "gnu.hash" returned a number of hits. One is:: http://code.linuxonly.nl/code/gnuhash.html

Check it out. Sounds like some GCC default got fouled up perhaps.

bgoodr

The page has my exact error message (or a close facsimile) so it would seem to be a good place to start (that hadn't occurred to me that it could be the problem...)

I tried running "objcopy -R .gnu.hash a.out", only to find gdb telling me the same thing (and still saying it doesn't know .gnu.hash).

This is starting to sound like bug territory...
 
Old 08-24-2007, 01:54 AM   #12
bgoodr
Member
 
Registered: Dec 2006
Location: Oregon
Distribution: RHEL[45] {x86,x86_64}, Debian "testing" {x86,x86_64}
Posts: 219

Rep: Reputation: 36
Quote:
Originally Posted by jakykong View Post
by the way, ls is never in /usr )
Shucks, you are right. That's what I get for responding by way of the Internet connection on my cell phone, and not from my Linux box where I could have done a "which ls" first.

That link indicates that "There are two ways around this: update GDB, or use objcopy". So, I think upgrading the GDB is one approach, which you've already started apparently. But, this next URL leads me to suspect a bug or two in the version of binutils you have on your system versus mine:

From http://www.nabble.com/GNU-hash-style...-t4265701.html

Quote:
Well, it sounds like a bug in binutils 2.17. There are so many of them
and they have been fixed in the current binutils. I don't want to spend
time on it unless it is reproducible in the current binutils.
What version of binutils do you have installed? I have this version installed, as reported by rpm which is Fedora's package manager:

Code:
bash-3.2$ rpm -q --whatprovides /usr/bin/objdump
binutils-2.17.50.0.12-4
So I read that to mean binutils version 2.17 plus bug fixes.

Is your system completely up to date according to the Debian package management system?

bgoodr
 
Old 08-24-2007, 02:45 AM   #13
jakykong
Member
 
Registered: Apr 2006
Location: Washington
Distribution: Debian Gnu/Linux Lenny on AMD64x2 (32-bit mode), an AMD Sempron 64 laptop, debian, 32bit
Posts: 101

Original Poster
Rep: Reputation: 15
I have binutils version 2.17cvs20070804-1. I read that as "the latest version as of the 4th of this month", which isn't that long ago...

But I do notice another fishy thing. The second link notes that this problem doesn't occur on other architectures, only x86_64. Granted, I'm using AMD64 (they ARE different, but primarily in their boot process, not their running instruction set), but when running they're basically the same.

I almost wonder if this is one of those "moving to 64-bit" problems. I wonder how long it will be before more people adopt 64-bit.

My next step, i guess, is to get a knoppix disk (big woop. I've got the ISO, i just never keep track of the CDs I have :-P), and try the same source code there (in 32-bit).
 
Old 08-24-2007, 03:23 AM   #14
bgoodr
Member
 
Registered: Dec 2006
Location: Oregon
Distribution: RHEL[45] {x86,x86_64}, Debian "testing" {x86,x86_64}
Posts: 219

Rep: Reputation: 36
Quote:
Originally Posted by jakykong View Post
Granted, I'm using AMD64 (they ARE different, but primarily in their boot process, not their running instruction set), but when running they're basically the same.
Can you explain what is different?

bgoodr
 
Old 08-24-2007, 11:13 AM   #15
jakykong
Member
 
Registered: Apr 2006
Location: Washington
Distribution: Debian Gnu/Linux Lenny on AMD64x2 (32-bit mode), an AMD Sempron 64 laptop, debian, 32bit
Posts: 101

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by bgoodr View Post
Can you explain what is different?

bgoodr
As I understand it (and it is really a pretty limited understanding) AMD followed the 16-32 path: that is, when a 32-bit chip starts up, it's in 16-bit 'real mode' until it's told to go into 32-bit 'protected mode'. AMD then has a 64-bit protected mode.

Intel starts out 64-bit, so 32-bit OS's have to have a special boot loader to enter 32-bit emulation mode to run.

AFAIK, that's the only significant difference between them. But having that difference may indicate other subtle ones that could change the scenario a bit.

Like I say, though, I'm only lightly-versed in processor architecture. I read an introductory book, to get a feel for what's going on under the hood (and what I did get out of it has certainly been helpful debugging some of my programs; But debugging a C program by hand and debugging a C++ program with gdb are different beasts entirely).

Last edited by jakykong; 08-24-2007 at 11:19 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
gdb "not in executable format: File format not recognized" tcma Programming 9 07-18-2007 07:02 AM
gdb won't recognize 64 bit executable on my RedHat 64 bits box cerniagigante Programming 1 02-23-2006 02:36 AM
gdb breakpoints cant find source file AM1SHFURN1TURE Programming 4 01-14-2006 02:10 PM
normal gdb and spec gdb for kgdb Igor007 Programming 1 09-23-2005 05:15 PM
/root/init.c: No File or Directory in GDB irfanhab Programming 2 01-29-2005 12:17 AM


All times are GMT -5. The time now is 04:56 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration