This is the mail archive of the 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: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

On Tue, Mar 06, 2007 at 09:31:14AM -0500, Jon Ringle wrote:
> Daniel Jacobowitz wrote:
> >On Mon, Mar 05, 2007 at 09:24:30PM -0500, Jon Ringle wrote:
> >  
> >>My target uses uclibc-0.9.28 rather than a glibc libc. Could that be a 
> >>factor here?
> >>    
> >
> >Yes, it certainly could be.
> >
> >  
> When I use a native gdb-6.6 on the uclibc target, I don't see any 
> SIGUSR1 signals being intercepted by gdb (so I don't have to do 'handle 
> SIGUSR1 nostop noprint') and I see correct behaviour using 'next'. What 
> would gdbserver-6.6 be doing different that a native gdb-6.6 in regards 
> to signal handling?

It may have decided that they are used by uClibc's threading library.
Beyond here I do not think I can make any useful guesses; all the
logic is different between gdb and gdbserver.  You'd have to debug it.

If it's decided threading uses them, "handle SIGUSR1" should show
nostop noprint alreayd.  Otherwise, it may just never be notified of
the signal - that would be a bug somewhere.

Daniel Jacobowitz

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