gdb won't recognize a.out file format

jakykong · 08-24-2007, 10:36 AM

I finally plugged my laptop in (brand new dual-core 2.6ghz processor with DDR2-800 ram sure beat out a single-core 1.4ghz processor with ddr2-400

) It has a 32-bit installation, but otherwise matches my desktop.

gdb ran on the same source code compiled by the same version of g++ no problem. It would appear to be a problem with the AMD64 architecture. And, by the links, I'm not the only one to have the problem.

Thanks for the help! I'll just have to reinstall; no biggie.

bgoodr · 08-24-2007, 12:12 PM

Quote:

Originally Posted by jakykong

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).

I didn't know that about the boot loading, but that makes sense to me. I've only had AMD CPU's in my machines. Here is what /proc/cpuinfo displays when read:

Code:

sh-3.2$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 75
model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
stepping	: 2
cpu MHz		: 1000.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips	: 2010.23
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 75
model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
stepping	: 2
cpu MHz		: 1000.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips	: 2010.23
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

sh-3.2$

jakykong · 08-25-2007, 05:21 AM

I never really cared for intel chips. It's not so much the chips (although I hold the firm belief that AMD's lower clock speeds lower temperatures), but the general selection of mainboards (IMO, more important than the chip, since mainboards require drivers). That's a debate that always has, and always will, rage among techs (as long as both intel and AMD exist, anyway). Personally, it's still an opinion, and I'll stick to my usual phrase: "Whatever works."

Anyway...

I finally managed to strip the .gnu.hash section out of a (known-working) a.out file (as it turned out, it was a typo. My .bash_history file reveals I had previously typed it as .gnu.hast, hence why objcopy didn't remove .gnu.hash). I ran the stripped a.out file with gdb, to find that the a.out file worked fine. However, every .so file on my system has a .gnu.hash file that is complained about -- on a simple Hello, World written in C, the number of complaints about .gnu.hash scrolled off my terminal.

I did a little more googling, now with some idea where to look, and the current CVS snapshot *should* have this bug fixed, according to several articles. I'm going to download and try that before I reinstall, here's hoping.

Either way, it is a problem with the 64-bit version of gdb, and I'm not at fault for it

Thanks for the help!