This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: how to debug deman-loaded programs
- From: "Banibrata Dutta" <dutta at india dot hp dot com>
- To: "'Ian Wienand'" <ianw at gelato dot unsw dot edu dot au>
- Cc: <binutils at sources dot redhat dot com>
- Date: Wed, 28 Apr 2004 10:11:33 +0530
- Subject: RE: how to debug deman-loaded programs
hi ian,
infact i tried to think of a better place to ask this question
but could not. i'd try findout and linking with the debug-enabled
version of glibc.
arch = x86 (i686)
os = redhat linux advanced-server 2.1 (RHAS-2.1)
gcc version = 2.96
g++ version = 2.96
ld version = 2.11.90.0.8 (supported emul: elf_i386, i386linux,
elf_i386_glibc21)
example:
--------
executable = RegTester (the exe)
sources that make up RegTester = RegTester.C, DynamicLoader.C, Scripting.C,
Plugin.C
shared-object = libproto.so
sources that make up libproto.so = Plugin.C, ProtoPlugin.C (note Plugin.C is
in both exe as well as in .so, without think linking of individual units
fail).
i run RegTester, and it gets SEGV leading to core. load core in gdb, and it
gives
a stack of 6 frames of which deepest 3 are in ProtoPlugin.C, and outer 3 are
in RegTester.C, DynamicLoader.C and Plugin.C.
when i do list, and try to pring a local variable in a stack frame, it works
from
frame # 4 onwards, i.e. Plugin.C onwards, but not for ProtoPlugin.C etc,
i.e. which
are not part of RegTester, but demand-loaded into RegTester.
i hope that explains the situation.
regards & thanks in advance for all the help/info,
bdutta.
> -----Original Message-----
> From: ianw@cse.unsw.edu.au [mailto:ianw@cse.unsw.edu.au] On
> Behalf Of Ian Wienand
> Sent: Wednesday, April 28, 2004 9:59 AM
> To: Banibrata Dutta
> Cc: binutils@sources.redhat.com
> Subject: Re: how to debug deman-loaded programs
>
>
> On Wed, Apr 28, 2004 at 09:51:27AM +0530, Banibrata Dutta wrote:
> > how does one debug a demand-loaded part of a process, i.e.
> the fault
> > is suspected in the shared object part of a program, which has been
> > loaded on-demand using dlopen()/dlsym(), but when i run gdb
> on it (or
> > it's "core"), going to a stack frame, and doing list,
> doesn't provide
> > me with any info, but simply prints out "rtld.c", that's it. all my
> > code is compiled with "-g" option.
>
> At a minimum, I'd say you need versions of the glibc
> libraries with debugging information available. On Debian,
> for example, you would install the libc6.1-dbg packages, and
> run gdb with LD_LIBRARY_PATH=/usr/lib/debug.
>
> This isn't a binutils thing however, so isn't appropriate for
> this list (actually, I'm struggling to think where to take
> these problems, probably one of your distribution support
> lists or IRC -- include what architecture and some example
> code for more responses).
>
> -i
>