public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Re: gdb6.0 and statically linked threaded programs
@ 2003-10-23 20:34 Todd.Kneisel
  2003-10-23 20:35 ` Daniel Jacobowitz
  0 siblings, 1 reply; 6+ messages in thread
From: Todd.Kneisel @ 2003-10-23 20:34 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb


>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.
>
>In the mean time I recommend using gdbserver instead of native gdb.
>
>--
>Daniel Jacobowitz
>MontaVista Software                         Debian GNU/Linux Developer

I just tried gdbserver and it's broken worse than native gdb. For both
statically and dynamically linked threaded programs, gdbserver fails
the same way that native gdb does for statically linked programs.

Todd Kneisel.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gdb6.0 and statically linked threaded programs
  2003-10-23 20:34 gdb6.0 and statically linked threaded programs Todd.Kneisel
@ 2003-10-23 20:35 ` Daniel Jacobowitz
  2003-10-24 21:01   ` Andrew Cagney
  0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-10-23 20:35 UTC (permalink / raw)
  To: Todd.Kneisel; +Cc: gdb

On Thu, Oct 23, 2003 at 01:33:55PM -0700, Todd.Kneisel@Bull.com wrote:
> 
> >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.
> >
> >In the mean time I recommend using gdbserver instead of native gdb.
> >
> >--
> >Daniel Jacobowitz
> >MontaVista Software                         Debian GNU/Linux Developer
> 
> I just tried gdbserver and it's broken worse than native gdb. For both
> statically and dynamically linked threaded programs, gdbserver fails
> the same way that native gdb does for statically linked programs.

Then you have gdbserver set up wrong or are using an older version -
I've tested it recently.  You'll have to investigate more.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gdb6.0 and statically linked threaded programs
  2003-10-23 20:35 ` Daniel Jacobowitz
@ 2003-10-24 21:01   ` Andrew Cagney
  0 siblings, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2003-10-24 21:01 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Todd.Kneisel, gdb

> 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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gdb6.0 and statically linked threaded programs
@ 2003-10-25  0:09 Todd.Kneisel
  0 siblings, 0 replies; 6+ messages in thread
From: Todd.Kneisel @ 2003-10-25  0:09 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb


> On Thu, Oct 23, 2003 at 01:33:55PM -0700, Todd.Kneisel@Bull.com wrote:
> > I just tried gdbserver and it's broken worse than native gdb. For both
> > statically and dynamically linked threaded programs, gdbserver fails
> > the same way that native gdb does for statically linked programs.
>
> Then you have gdbserver set up wrong or are using an older version -
> I've tested it recently.  You'll have to investigate more.
>
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

I've found that gdbserver is failing because we're on an ia64 system.
The configure.srv file uses the default srv_linux_thread_db=no for ia64
systems, which disables the code that initializes the thread layer.

I changed srv_linux_thread_db to yes and reconfigured and now the thread
layer is initialized, but breakpoints are not implemented for the ia64
in gdbserver.

We're evaluating our options now. We may go back to gdb 5 and live without
the stack traces that were fixed for ia64 in gdb 6.

Thanks for your help,
Todd Kneisel.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gdb6.0 and statically linked threaded programs
  2003-10-22 23:00 Todd.Kneisel
@ 2003-10-23 12:24 ` Daniel Jacobowitz
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-10-23 12:24 UTC (permalink / raw)
  To: Todd.Kneisel; +Cc: gdb

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.

In the mean time I recommend using gdbserver instead of native gdb.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 6+ messages in thread

* gdb6.0 and statically linked threaded programs
@ 2003-10-22 23:00 Todd.Kneisel
  2003-10-23 12:24 ` Daniel Jacobowitz
  0 siblings, 1 reply; 6+ messages in thread
From: Todd.Kneisel @ 2003-10-22 23:00 UTC (permalink / raw)
  To: gdb

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?

Thanks,
Todd Kneisel


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-10-25  0:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-23 20:34 gdb6.0 and statically linked threaded programs Todd.Kneisel
2003-10-23 20:35 ` Daniel Jacobowitz
2003-10-24 21:01   ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2003-10-25  0:09 Todd.Kneisel
2003-10-22 23:00 Todd.Kneisel
2003-10-23 12:24 ` Daniel Jacobowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).