using gdb on linux

using gdb on linux

Post by Sandeep Grove » Tue, 09 Apr 2002 20:31:20



Hi.

I have a product with a C-executable which allows  users to write their
own shared objects
which then are loaded using "dlopen". Now, if my customer want to debug
his own
code using gdb, he cannot find his function-name until run-time when we
load their
shared object. And now since our code is not debuggable, he cannot stop
in between
my code to set a breakpoint in his code.

surprisingly, In solaris, one can set a break point in main executable
even if
its not debuggable , although you still cannot see stack trace and any other
usable information, but still this allows you to set up a debug point in
your own code which is debbuggable.

Do anyone know whythis happens ? and is there any way to mimic the behaviour
of solaris on Linux ?

I do not know where to put this stuff.....

please let me know the solution for thsi.....

thanks
Sandeep

 
 
 

using gdb on linux

Post by Rick Avr » Fri, 12 Apr 2002 05:39:04


I'm a little rusty with this but here's what I would try. If possible, I
would execute a dlsym after the dlopen to get the location of newly loaded
object. Print this value out and then put it into .gdbinit using
add-symbol-file foo.so NewFooAddress. Follow that in .gdbinit with a
breakpoint somewhere in the shared object (e.g. b foofunction:1). gdb will
read .gdbinit on invocation.

I have found that running on the same machine, an object will usually land
in the same memory location in sequential runs although it would be worth
running several times in sequence to see if this is true with your set-up.
This obviously depends on having enough memory to avoid swapping.

-Rick


Quote:> Hi.

> I have a product with a C-executable which allows  users to write their
> own shared objects
> which then are loaded using "dlopen". Now, if my customer want to debug
> his own
> code using gdb, he cannot find his function-name until run-time when we
> load their
> shared object. And now since our code is not debuggable, he cannot stop
> in between
> my code to set a breakpoint in his code.

> surprisingly, In solaris, one can set a break point in main executable
> even if
> its not debuggable , although you still cannot see stack trace and any
other
> usable information, but still this allows you to set up a debug point in
> your own code which is debbuggable.

> Do anyone know whythis happens ? and is there any way to mimic the
behaviour
> of solaris on Linux ?

> I do not know where to put this stuff.....

> please let me know the solution for thsi.....

> thanks
> Sandeep


 
 
 

1. Using GDB to debug a program that uses fork(2)?

This is driving me *nuts*.  I'm trying to use GDB to debug a
daemon which has a fork(2) call in it.  How do I tell
GDB to continue debugging the child after the parent process
dies?  I've looked in the manual, and didn't see anthing which
addresses this directly.

I tried to use "attach" on the running daemon, but when I
did, I got an error message saying "Can't attach to process
on this machine."

I'm working on a Silicon Graphics Indigo Elan, running
IRIX 4.0.5.  The GDB version is 4.7, compiled with
gcc-2.3.3.

What am I doing wrong?  Any ideas?

Thanks,

Tim

2. Solaris Porting Project Help Request

3. Trouble with gdb&Linux using transitive linked shared libraries

4. Solaris 2.5 and SunOS Diskless Clients

5. trouble using gdb on Linux

6. delete a folder

7. debugging a shared library using gdb on linux

8. Difficulties compiling qt-2.0-based snapshots

9. Using gdb with Linux Elf shared object libraries

10. Interfacing with gdb: How to set a gdb watch point from C++ code?

11. gdb problem (gdb 4.8, gcc 2.6.2)

12. please HELP with GDB output redirect to GDB variable !!!

13. binutils, bugs in gdb, & "fixes" to gdb