Re: breakpoint in lib.so loaded by a multi-threaded application on PC-Intely

[Roland Egger <egger@tarantel.rz.fh-muenchen.de>]

Hi Denis,
at the moment I don't have an example on my machine here but I would try
something similar. If it's not possible to break at dlopen I would set
the breakpoint the lines before or afterwards but before using any
functions methods ... of the loaded libraries. After the lib(s) have been
loaded it's possible to use breakpoints in the shared library

We load the libMyDll.so with the Class OTest

// ... here's something before the dlopen and of course somewhere here we can
// set our breakpoint if it doesn't work on dlopen
void *handle = dlopen ("/lib/libMyDll.so", RTLD_LAZY);
// after we stept with next over dlopen we can set the breakpoint inside
// libMyDll.so
OTest oMyTest; // now we can go to the constructor  with stepi or perhaps
               // the breakpoint ???

Is that what you want to do??

Ciao
   Roland



On Tue, Dec 03, 2002 at 03:51:34PM +0100, Denis Milhet wrote:
> Hi Roland !
> 
> Thank's for your answer !
> I use Linux (Red-Hat 7.2) and I'm actually porting applications running on
> Sun Solaris and PC-WinNT to PC-Linux.
> In these applications, built with shared libraries and written in C++, I
> need to debug code initialised durind the libraries loading (eg constructor
> of variables). Of course it's impossible to put a breakpoint on the symbol
> of such function before its dynamic loading, and the feature "catch load" of
> gdb doesn't seem to be available on Linux according to the error message
> "catch of library loads/unloads not yet implemented on this plateform" and
> according to the gdb documentation.
> Do you know a solution ? Is it possible to force gdb to load and keep
> symbols on shared libraries in order to stop on them during execution ? For
> example with Sun Solaris dbx, the instruction "stop when dlopen" allows such
> feature. Is it easier to put a breakpoint on the "dlopen" symbol (I've
> tried, it doesn't work but perhaps didn't enter the right order of commands
> ...) ? It should be less convenient because gdb will stop in each loading.
> 
> Thank's for your help,
> 
> Denis
>