gdb-6.3.0.0-1.131.EL4 1. Compile a test program on a 32-bit RHEL3, with gcc 2.96 $ cat test.c #include <stdio.h> #include <stdlib.h> #include <string.h> int main(int argc, char ** argv) { float f = 4.5; printf("%f\n", f); return 0; } $ gcc296 -g -o test test.c 2. Copy the binary to a RHEL4 x86-64 machine 3. Run in gdb: $ gdb ./test (gdb) b 8 Breakpoint 1 at 0x8048429: file test.c, line 8. (gdb) run Starting program: /home/bnocera/test Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 Breakpoint 1, main (argc=1, argv=0xffffd8a4) at test.c:8 8 } (gdb) p f Cannot access memory at address 0xffffd814 On RHEL3 x86, and RHEL4 x86, "f" shows up properly: (gdb) p f $1 = 4.5
Running 32-bit gdb on x86_64 seems to work around the memory access problems, but then has difficulty with pthreaded apps. Static linking works around the pthreading difficulty and seems to allow 32-bit gdb to properly debug pthreaded gcc296 binaries on x86_64, at least in the test case.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.