Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/4.75 [fr] (X11; U; Linux 2.2.12-20 i686) Description of problem: When tracing a program that opens a shared library with 'dlopen', gdb cannot find correct information on symbols provided by the shared library. I assume this is a bug as it worked properly in former versions of redhat linux (6.1, and I believe also 6.2) How reproducible: Always Steps to Reproduce: 0. take the files from the given URL above 1. type make 2. launch 'gdb main', type 'break 11', 'r'. At the break point, the main program is supposed to have dlopened (RTLD_NOW) a shared lib 'test.so' containing a function 'test', and to have loaded the symbol 'test'. 3. type 'p test' or 'break test'. Actual Results: (gdb) p test $1 = {<text variable, no debug info>} 0x400187c0 <test> (gdb) break test Cannot access memory at address 0x123 Expected Results: This is what happens with a RH-6.1 distro (and as far as I remember, also for a RH-6.2): (gdb) p test $1 = {void ()} 0x400137f8 <test> (gdb) break test Breakpoint 2 at 0x400137fe: file test.c, line 4. Additional info: I assume that this is a GDB bug (and NOT gcc or ld), since: compile under 6.1 and debug under 7.1 fails the same way as when I compile and debug under 7.1.
I can reproduce the problem... but get the exact same messages with the gdb shipped with 6.2 on a RHL 7.1 system. Jakub, do you know what could cause this?
"--readnow" should help some, but something's still not quite right.
The --readnow option to gdb helps to a very limited extent. Most notably, source code following is not quite correct. When setting a breakpoint to function test in test.c, I get: Breakpoint 2, 0x400187c6 in test () at eval.c:41 I'm wondering where this 'eval.c' file comes from.
The vanilla gdb-5.0 compiled with the updated gcc (gcc-2.96-85 from redhat-updates 7.1) seems to behave properly now. It seems that this bug was triggered in some way by the buggy compiler. This taken into account, the bug can be considered as CLOSED.
Fixed in new compiler.