This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]