Re: gdb + sigtraps

[christos%astron.com@localhost (Christos Zoulas)]

In article <201203192317.q2JNHgWW016757%ginseng.pulsar-zone.net@localhost>,
Matthew Mondor  <mm_lists%pulsar-zone.net@localhost> wrote:
>On Mon, 19 Mar 2012 18:02:28 +0000
>Patrick Welche <prlw1%cam.ac.uk@localhost> wrote:
>
>> When trying to debug my favorite program dasher on -current/amd64 using
>> gdb, I keep getting sigtraps. This makes life difficult, but seems to be
>> "recent". e.g.,
>> gdb dasher
>> break sendText
>> c
>> now I will get sigtraps, keep continuing until my break point is reached
>> s
>> and we are back to sigtraps and I can't step to the next line...
>> This isn't what used to happen...
>> 
>> Any ideas where to look?
>
>I think that I've also got this when debugging a particular program on
>netbsd-6/amd64 (I forgot which at the moment though), and of course if
>telling gdb to ignore it, it'd just be stuck...

The problem is that the internal breakpoint trap that is being inserted
by gdb to rtld to catch when a library is loaded, is not treated as internal
and it causes a breakpoint to the user. This breakpoint is used to recognize
when libpthread is loaded for example, so that the debugger can switch to
multi-threaded mode. As far as libpthread_dbg is concerned, this provides
a sanctioned way to look at the internals of the pthread library without
exposing the guts to the debugger. This is what the tdb_ abstraction is for.
I think we should keep it.

christos