gdbserver signals interfere with {next,step{,i}}

gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

Hello,

I have an application that uses SIGUSR1 to receive timer interrupts. 
I've done 'handle SIGUSR1 nostop noprint' to avoid gdb from stopping on 
SIGUSR1.
I've found that when debugging this application using gdbserver, that I 
can't use next, nexti, step, or stepi. When I use one of these commands, 
the application usually just continues without stopping at the next 
line/instruction.

If I use a native gdb on the target the problem does not occur.
If I disable my app from generating the SIGUSR1 and use gdbserver, the 
problem also goes away.

I am using gdb-6.6 for gdbserver, native gdb and cross gdb.

Jon

Re: gdbserver signals interfere with {next,step{,i}}

[Daniel Jacobowitz]

On Mon, Mar 05, 2007 at 03:05:34PM -0500, Jon Ringle wrote:
> Hello,
> 
> I have an application that uses SIGUSR1 to receive timer interrupts. 
> I've done 'handle SIGUSR1 nostop noprint' to avoid gdb from stopping on 
> SIGUSR1.
> I've found that when debugging this application using gdbserver, that I 
> can't use next, nexti, step, or stepi. When I use one of these commands, 
> the application usually just continues without stopping at the next 
> line/instruction.
> 
> If I use a native gdb on the target the problem does not occur.
> If I disable my app from generating the SIGUSR1 and use gdbserver, the 
> problem also goes away.

I haven't seen this problem before.  Can you make a small test case
which demonstrates the problem, maybe?

What target are you using?

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

Daniel Jacobowitz wrote:
> On Mon, Mar 05, 2007 at 03:05:34PM -0500, Jon Ringle wrote:
>   
>> Hello,
>>
>> I have an application that uses SIGUSR1 to receive timer interrupts. 
>> I've done 'handle SIGUSR1 nostop noprint' to avoid gdb from stopping on 
>> SIGUSR1.
>> I've found that when debugging this application using gdbserver, that I 
>> can't use next, nexti, step, or stepi. When I use one of these commands, 
>> the application usually just continues without stopping at the next 
>> line/instruction.
>>
>> If I use a native gdb on the target the problem does not occur.
>> If I disable my app from generating the SIGUSR1 and use gdbserver, the 
>> problem also goes away.
>>     
>
> I haven't seen this problem before.  Can you make a small test case
> which demonstrates the problem, maybe?
>
>   
Attached is a test case. <cid:part1.03040401.03010207@ringle.org>
> What target are you using?
>
>   
My target is armeb-linux.

Thanks,

Jon


[-- Attachment #2: gdbsignal-test.c --]
[-- Type: text/plain, Size: 2190 bytes --]

#include <stdio.h>
#include <pthread.h>
#include <signal.h>

static void signal_handler (int signo);
static timer_t   timer_id       = -1;
#define ERROR (-1)

int i = 0;
void signal_handler(int signo)
{
	// Perform a use-less task
	i++;
}

void init_signals (void)
{
	struct sigaction  sig_act;
	struct sigevent   evp;
    	struct itimerspec   ttime;
    
	/* initialize sig_act */
	sig_act.sa_handler = (void*)signal_handler;
	sig_act.sa_flags   = 0;
	sigemptyset(&sig_act.sa_mask);

	sigaction(SIGUSR1, &sig_act, 0);
	
	evp.sigev_value.sival_int = 0;
	evp.sigev_signo = SIGUSR1;
        timer_create (CLOCK_REALTIME, &evp, &timer_id);

	ttime.it_value.tv_sec     = 0;          /* 0  S */
	ttime.it_value.tv_nsec    = 20000000;   /* 20mS */
	ttime.it_interval.tv_sec  = 0;          /* 0  S */
	ttime.it_interval.tv_nsec = 20000000;   /* 20mS */
	
	/* fire off the periodic timer - relative mode = 0 */
	timer_settime(timer_id, 0, &ttime, NULL);
}

static int get_input(char *buffer, int size)
{
	char    c;
	int     status, counter, dummy;
	
	counter= 0;
	c      = 0;
	status = 0;
	
	while (c != '\r')
	{
		dummy = getc(stdin);
		c = (char)dummy;
		
		if ((dummy != EOF) && (dummy != 0)) {
			if ( isprint(c) && (counter < size-1) )  {
				buffer[counter++] = c;
			} else if ((c == '\r') || (c == '\n')) {
				/* return user's str length - while loop will terminate */
				status = counter;
				
				c = '\r';
			} else  {
				; /* Ignore any other characters */
			}
			
		} else {
			memset (buffer, 0, size);
			
			counter = 0;
			if (dummy == 0)
				printf ("\nreceived NULL!\n");
			
			else
				printf ("\n\nGot EOF!\n");
			sleep(10);
			c      = '\r';
			status = ERROR;
		}
	}
	buffer[counter] = 0;
	return status;
}

void* thread(void* dummy)
{
	init_signals();

	while (1)
		;
	return NULL;
}

int main(int argc, char* argv[])
{
	pthread_t tid;
	pthread_create(&tid, NULL, &thread, NULL);
	while (1)
	{
		char buffer[200];
		printf ("Prompt %d> ", i);
		get_input(buffer, sizeof(buffer));

		// Give ourselves something to next...
		printf("Got "); // <<<<<<<<<<<<< Put breakpoint here 
		printf("'%s'", buffer);
		printf("\n");
	}
	pthread_join(tid,NULL);
	return 0;
}
	    

Re: gdbserver signals interfere with {next,step{,i}}

[Michael Snyder]

On Mon, 2007-03-05 at 15:05 -0500, Jon Ringle wrote:
> Hello,
> 
> I have an application that uses SIGUSR1 to receive timer interrupts. 
> I've done 'handle SIGUSR1 nostop noprint' to avoid gdb from stopping on 
> SIGUSR1.
> I've found that when debugging this application using gdbserver, that I 
> can't use next, nexti, step, or stepi. When I use one of these commands, 
> the application usually just continues without stopping at the next 
> line/instruction.
> 
> If I use a native gdb on the target the problem does not occur.
> If I disable my app from generating the SIGUSR1 and use gdbserver, the 
> problem also goes away.
> 
> I am using gdb-6.6 for gdbserver, native gdb and cross gdb.

Is it possible for your app to use a different signal?
SIGUSR1 has been used by glibc in the old linux pthreads
implementation, and gdb (and gdbserver) both have special
handling built into them for that signal.

Re: gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

Michael Snyder wrote:
> On Mon, 2007-03-05 at 15:05 -0500, Jon Ringle wrote:
>   
>> Hello,
>>
>> I have an application that uses SIGUSR1 to receive timer interrupts. 
>> I've done 'handle SIGUSR1 nostop noprint' to avoid gdb from stopping on 
>> SIGUSR1.
>> I've found that when debugging this application using gdbserver, that I 
>> can't use next, nexti, step, or stepi. When I use one of these commands, 
>> the application usually just continues without stopping at the next 
>> line/instruction.
>>
>> If I use a native gdb on the target the problem does not occur.
>> If I disable my app from generating the SIGUSR1 and use gdbserver, the 
>> problem also goes away.
>>
>> I am using gdb-6.6 for gdbserver, native gdb and cross gdb.
>>     
>
> Is it possible for your app to use a different signal?
> SIGUSR1 has been used by glibc in the old linux pthreads
> implementation, and gdb (and gdbserver) both have special
> handling built into them for that signal.
>
>
>   
I just tried the test case I posted to the list with SIGUSR2 instead 
with the same results.

Jon

Re: gdbserver signals interfere with {next,step{,i}}

[Michael Snyder]

> > Attached is a test case. 

What library do I link to for timer_create?

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

Michael Snyder wrote:
>>> Attached is a test case. 
>>>       
>
> What library do I link to for timer_create?
>
>
>   
This is how I built the testcase:
$ CC=armeb-linux-gcc LDFLAGS="-lrt -lpthread" CFLAGS="-g" make 
gdbsignal-test

Jon

Re: gdbserver signals interfere with {next,step{,i}}

[Michael Snyder]

On Mon, 2007-03-05 at 20:47 -0500, Jon Ringle wrote:
> Michael Snyder wrote:
> >>> Attached is a test case. 
> >>>       
> >
> > What library do I link to for timer_create?
> >
> >
> >   
> This is how I built the testcase:
> $ CC=armeb-linux-gcc LDFLAGS="-lrt -lpthread" CFLAGS="-g" make 
> gdbsignal-test

OK, I built it with arm-linux-gcc -lrt -lpthread -g 

I copied it to my arm dev board running kernel 2.6.14
(intel Zylonite)

I started it under gdbserver 6.5, connected to it with gdb 6.5, 
break on line 106 as suggested by the comment, gave it some 
input, hit the breakpoint, nexted a few times...

I didn't see any odd behavior (I also didn't see gdb report any
SIGUSR1 events).

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

Michael Snyder wrote:
> OK, I built it with arm-linux-gcc -lrt -lpthread -g 
>
> I copied it to my arm dev board running kernel 2.6.14
> (intel Zylonite)
>
> I started it under gdbserver 6.5, connected to it with gdb 6.5, 
> break on line 106 as suggested by the comment, gave it some 
> input, hit the breakpoint, nexted a few times...
>
> I didn't see any odd behavior (I also didn't see gdb report any
> SIGUSR1 events).
>
>   
Hmm...
My target uses uclibc-0.9.28 rather than a glibc libc. Could that be a 
factor here?

Jon

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

Michael Snyder wrote:
> OK, I built it with arm-linux-gcc -lrt -lpthread -g 
>
> I copied it to my arm dev board running kernel 2.6.14
> (intel Zylonite)
>
> I started it under gdbserver 6.5, connected to it with gdb 6.5, 
> break on line 106 as suggested by the comment, gave it some 
> input, hit the breakpoint, nexted a few times...
>
> I didn't see any odd behavior (I also didn't see gdb report any
> SIGUSR1 events).
>
>   
Did you do a 'handle SIGUSR1 nostop noprint' to avoid seeing SIGUSR1 events?
Did the "Prompt %d" increment as you proceeded with the test?

Other details about my target: linux 2.6.16.29, uclibc-0.9.28, gdbserver 
6.6, gdb 6.6, armeb-linux-gcc 3.4.6

Jon

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

Michael Snyder wrote:
> I started it under gdbserver 6.5, connected to it with gdb 6.5, 
> break on line 106 as suggested by the comment, gave it some 
> input, hit the breakpoint, nexted a few times...
>   
I tried with gdbserver 6.5 and gdb 6.5 and I get the same odd behaviour 
as I do with 6.6.

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

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?

Jon

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Daniel Jacobowitz]

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
CodeSourcery

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

Daniel Jacobowitz wrote:
> 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.
>
>   
Sorry, my bad here. I had been playing around with using different 
signals last night and left the code using SIGALRM instead, which 
defaults to nostop noprint. When I switched back to using SIGUSR1 again, 
I had to use 'handle SIGUSR1 nostop noprint' on the native gdb.

Jon

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Michael Snyder]

On Mon, 2007-03-05 at 21:24 -0500, Jon Ringle wrote:
> Michael Snyder wrote:
> > OK, I built it with arm-linux-gcc -lrt -lpthread -g 
> >
> > I copied it to my arm dev board running kernel 2.6.14
> > (intel Zylonite)
> >
> > I started it under gdbserver 6.5, connected to it with gdb 6.5, 
> > break on line 106 as suggested by the comment, gave it some 
> > input, hit the breakpoint, nexted a few times...
> >
> > I didn't see any odd behavior (I also didn't see gdb report any
> > SIGUSR1 events).
> >
> >   
> Hmm...
> My target uses uclibc-0.9.28 rather than a glibc libc. Could that be a 
> factor here?

Could be.  In fact, almost certainly.  GDB thread support depends on
libthread_db which is part of glibc.  does uclibc include a similarly
named library?

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Michael Snyder]

On Tue, 2007-03-06 at 09:31 -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'.

Important question -- does gdb thread support (either native or
remote/gdbserver) work at all with uclibc?

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

Michael Snyder wrote:
> GDB thread support depends on
> libthread_db which is part of glibc.  does uclibc include a similarly
> named library?
>
>   
Yes:
# ls -l /lib/libpthread*
-rw-r--r--    1 root     root        87795 Mar  4  2007 
/lib/libpthread-0.9.28.so
lrwxrwxrwx    1 root     root           20 Mar  4  2007 
/lib/libpthread.so.0 -> libpthread-0.9.28.so
# ls -l /lib/libthread_db*
-rw-r--r--    1 root     root        11472 Mar  4  2007 
/lib/libthread_db-0.9.28.so
lrwxrwxrwx    1 root     root           22 Mar  4  2007 
/lib/libthread_db.so.1 -> libthread_db-0.9.28.so

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Jon Ringle]

Michael Snyder wrote:
> On Tue, 2007-03-06 at 09:31 -0500, Jon Ringle wrote:
>   
>> 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'.
>>     
The above comment about SIGUSR1 is incorrect. When I ran the test, I was 
actually using SIGALRM which is why I didn't see any SIGUSR1 events... 
sorry for the confusion there.
>
> Important question -- does gdb thread support (either native or
> remote/gdbserver) work at all with uclibc?
Yes, thread support seems to work just fine from both native gdb and 
gdbserver <-> crossgdb scenarios. "info threads" shows me a list of 
threads and I can use the "thread" command to switch thread contexts and 
see a backtrace of each thread.

Jon

Re: [SPAM] Re: gdbserver signals interfere with {next,step{,i}}

[Daniel Jacobowitz]

On Tue, Mar 06, 2007 at 11:46:11AM -0800, Michael Snyder wrote:
> Important question -- does gdb thread support (either native or
> remote/gdbserver) work at all with uclibc?

Yes - both.

-- 
Daniel Jacobowitz
CodeSourcery