symtab/2203: Wrong or no debug information in shared libs

JurgenvonOerthel@hotmail.com JurgenvonOerthel@hotmail.com
Wed Nov 22 14:18:00 GMT 2006


>Number:         2203
>Category:       symtab
>Synopsis:       Wrong or no debug information in shared libs
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 22 14:18:01 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     JurgenvonOerthel@hotmail.com
>Release:        6.3.0.0-1.90rh
>Organization:
>Environment:
gdb 6.3.0.0-1.90rh, gcc 3.4.3, dwarf-2, C++, shared libs
>Description:
I have a lot of generated C++ code compiled into shared libs that are loaded dynamically.
When I break in one of the constructors in these libraries and do a backtrace then gdb always displays: .../include/c++/3.4.3/bits/locale_facets.tcc:2444 as source information for all of the constructors in the stack trace except for the highest two stack frames. The highest two stack frames are displayed correctly.

The calls to the constructors in the generated code are wrapped in macros. When I preprocess all the C++ files before compiling them and then rerun gdb, then no source information is shown in the backtrace other than the demangled constructor name and the library name (not even the constructor arguments are displayed).

When I use stabs instead of dwarf-2 then gdb displays the source information correctly.

Unfortunately I cannot supply a small example to demonstrate this behaviour. As additional information I can tell you that the C++ code contains a lot of (partially specialized) template classes, relies heavily on RTTI and contains static objects with dynamic initialization.
When I perform a "bt full" I see dozens of typeinfo and guard variable messages (before each of the stack frames without debug information). Maybe this is confusing gdb?
Source information is incorrect only for functions in the dynamically loaded libraries.
These libraries contain little more than constructors/destructors, so I'm not sure if the same problem exists for non-constructor functions.

Please let me know what I can do to provide you with additional information to solve this issue.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:



More information about the Gdb-prs mailing list