Shared Library Debugging with -ldl / gdb "eval.c" no such file

Shared Library Debugging with -ldl / gdb "eval.c" no such file

Post by M.Stipe » Sat, 17 Nov 2001 00:43:59



We have developed a tool wich itself accepts Plugins.
During development it is impossible the dlopend syms to be debugged with
gdb. The error is "eval.c":41 no such file.

GDB Version doesn't care, tried on Redhat Linux 6.0 6.1, 7.0, 7.1 and 7.2.

 
 
 

Shared Library Debugging with -ldl / gdb "eval.c" no such file

Post by Jens.Toerr.. » Sat, 17 Nov 2001 01:44:39



Quote:> We have developed a tool wich itself accepts Plugins.
> During development it is impossible the dlopend syms to be debugged with
> gdb. The error is "eval.c":41 no such file.
> GDB Version doesn't care, tried on Redhat Linux 6.0 6.1, 7.0, 7.1 and 7.2.

If "eval.c" is your source code I would guess that you have moved the
sources to a different place from where they where when you compiled
the program. At least otherwise I never had problems getting at
dlopen()'ed sources in gdb.
                                          Regard, Jens
--
      _  _____  _____

  _  | |  | |    | |          AG Moebius, Institut fuer Molekuelphysik
 | |_| |  | |    | |          Fachbereich Physik, Freie Universitaet Berlin
  \___/ens|_|homs|_|oerring   Tel: ++49 (0)30 838 - 53394 / FAX: - 56046

 
 
 

Shared Library Debugging with -ldl / gdb "eval.c" no such file

Post by M.Stipe » Sat, 17 Nov 2001 02:27:58


eval.c is not my source file it is one from gdb!
My sourcefile is e.g. "test-plugin.c".

(pseudo) Eaxample:
        main.c:main()
        ....
        testfunc=dlsym("testfunc_in_plugin");
        testfunc(arg1);

        plugin.c: testfunc()
        { printf("hallo");
          return;
        }

        I'll see in gdb:

Quote:>>We have developed a tool wich itself accepts Plugins.
>>During development it is impossible the dlopend syms to be debugged with
>>gdb. The error is "eval.c":41 no such file.

>>GDB Version doesn't care, tried on Redhat Linux 6.0 6.1, 7.0, 7.1 and 7.2.

> If "eval.c" is your source code I would guess that you have moved the
> sources to a different place from where they where when you compiled
> the program. At least otherwise I never had problems getting at
> dlopen()'ed sources in gdb.
>                                           Regard, Jens

 
 
 

Shared Library Debugging with -ldl / gdb "eval.c" no such file

Post by Jens.Toerr.. » Sat, 17 Nov 2001 02:54:49



Quote:> eval.c is not my source file it is one from gdb!
> My sourcefile is e.g. "test-plugin.c".
> (pseudo) Eaxample:
>    main.c:main()
>    ....
>    testfunc=dlsym("testfunc_in_plugin");
>    testfunc(arg1);
>    plugin.c: testfunc()
>    { printf("hallo");
>      return;
>    }
>    I'll see in gdb:

(Something seems to be missing in your post here...)

To be able to look into files from other libraries (i.e. eval.c) you
need to install the sources, create everything from them (with debugging
options switched on) and use this selfmade version.

But the more interesting question really is at what place in *your* code
the error results from. Even if the error happens in eval.c you still can
find out from which place in your own program you got there by doing a
backtrace (simply type 'bt'). And after the dlopen() was successful you
can set breakpoints in your library code.
                                               Regards, Jens
--
      _  _____  _____

  _  | |  | |    | |          AG Moebius, Institut fuer Molekuelphysik
 | |_| |  | |    | |          Fachbereich Physik, Freie Universitaet Berlin
  \___/ens|_|homs|_|oerring   Tel: ++49 (0)30 838 - 53394 / FAX: - 56046

 
 
 

Shared Library Debugging with -ldl / gdb "eval.c" no such file

Post by M.Stipe » Sat, 17 Nov 2001 02:55:44


I'm further. If I force a SIGSEV in an plugin
function I'll get the following backtrace :

Program received signal SIGSEGV, Segmentation fault.
0x4000d240 in fixup () at eval.c:41
41      eval.c: No such file or directory.
         in eval.c
(gdb) bt
#0  0x4000d240 in fixup () at eval.c:41
#1  0x4000d450 in _dl_runtime_resolve () at eval.c:41
#2  0x0804999e in xslp_create_XSLP_PROCESSOR (xslp_plugin=0x804be08) at
xslp_wrapper.c:49
#3  0x08048b15 in main (argc=3, argv=0xbffff914) at test-xslpwrapper.c:74
#4  0x40059507 in __libc_start_main (main=0x8048a10 <main>, argc=3,
ubp_av=0xbffff914, init=0x80487c0 <_init>, fini=0x8049db0 <_fini>,
rtld_fini=0x4000dc14 <_dl_fini>,
     stack_end=0xbffff90c) at ../sysdeps/generic/libc-start.c:129

Short explanation:
        - xslp_create_XSLP_PROCESSOR is a function in the xslp_wrapper  
          (not by plugin and is linked statically into the main). Itself
           calls _somefunction_at_plugin() which does some printf and a
           creating a sigsev for debugging (writing to some mem).

Strange is that, even if I step, I never won't see the function
  _somefunction_at_plugin() and I never had a chance to set breakp.

And: show shar tell me the lib is loaded (without the SIGSEV I've added
the plugin will do what it should do!). info func show me the symbols of
the plugin. What is the fact here? Could somebody explain?

 
 
 

Shared Library Debugging with -ldl / gdb "eval.c" no such file

Post by Paul Pluzhniko » Sat, 17 Nov 2001 15:07:19



Quote:> We have developed a tool wich itself accepts Plugins.
> During development it is impossible the dlopend syms to be debugged with
> gdb.

Try this:

  (gbd) set stop-on-solib-event 1

Each time gdb stops, issue "info shared" and see whether your
plugin is loaded yet.

Once it is, you can set breakpoints in it.

 
 
 

1. gdb/ddd shared library debugging problem

Hi group,
i am having problems stepping into the shared library code by using
gdb (with/without a frontend like ddd etc). i tried compiling the
shared libary with absoloute src path & relative path both ... also
tried setting the shared libray path in gdb but of no use.
every time i step into a shared library function it says cannot not
find eval.c in the search path. also the execution line number it
reports in eval.c is 41 which is same alway. (Note: my project does
not has any file called eval.c & the shared library is loaded through
dlopen() ).
please provide me as much as possible information regarding this or
correct me if i m doing soming wrong.
regards
amit tikare

2. Problems installing XFree86 3.2

3. Debug shared libraries with gdb ???

4. Kernel Change Summary 2.0.17

5. debugging shared libraries with gdb

6. username in processes list by ID

7. Will strip(debug shared library) == nodebug shared library ?

8. Dynamic IP & X?

9. How can i debug a shared library using gdb..

10. debugging shared libraries using gdb

11. Debugging shared libraries with gcc 2.95.2, gdb 4.18

12. debugging a shared library using gdb on linux

13. Debugging shared libraries. gdb unexpected behaviour.