This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB 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: gdb6.0 and statically linked threaded programs


On Wed, Oct 22, 2003 at 03:59:53PM -0700, Todd.Kneisel@Bull.com wrote:

I have built gdb6.0 and am having trouble using it to debug a
threaded program that is statically linked with the linuxthreads
pthread library. Gdb does not detect the creation of threads,
it traps signal 32 that the pthread library uses to restart
threads, and gets a SIGINT instead of stopping at a breakpoint
in a thread.

If I dynamically link my program, everything works fine. For
a number of reasons, I need to link my program statically.

I've begun looking at the gdb code and found the following
text in a comment in the thread_db_mourn_inferior function:

   At present,
   debugging a statically-linked threaded program is broken, but
   the check is added below in the event that it is fixed in the
   future.

Is anyone working on fixing this?  Or can anyone provide more
details about how or why it's broken?


It's broken because the thread layer is never initialized.  I'm waiting
for some of the changes to the target stack to see if they make it
easier to fix this - the last few things I've tried were simply gross
beyond words.

Daniel, suggest looking at: interface VS target (or something else wrong with the target vector) http://sources.redhat.com/ml/gdb/2003-10/msg00218.html

The implication is that immediatly after attaching to a process (or corefile) there'd be some sort of broadcast message telling any interested parties (thread stratum, overlay stratum, shlibs, ...) that there's a fresh new process/core to push onto.

But as you note, it will require some pushing and shoving to get there.

Andrew



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