Bug 41952 - GDB fails to see debugging symbols in dlopen'ed libraries
GDB fails to see debugging symbols in dlopen'ed libraries
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-05-23 03:23 EDT by Need Real Name
Modified: 2007-04-18 12:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-30 16:56:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-05-23 03:23:14 EDT
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:

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.
Comment 1 Trond Eivind Glomsrxd 2001-05-23 12:14:11 EDT
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?
Comment 2 Trond Eivind Glomsrxd 2001-05-23 12:23:38 EDT
"--readnow" should help some, but something's still not quite right.
Comment 3 Need Real Name 2001-05-24 05:59:13 EDT
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.
Comment 4 Need Real Name 2001-07-30 10:16:01 EDT
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.
Comment 5 Trond Eivind Glomsrxd 2001-07-30 16:56:18 EDT
Fixed in new compiler.

Note You need to log in before you can comment on or make changes to this bug.