Problems with remote debugging on ARM

Problems with remote debugging on ARM

[Milrith]

Hello,

I encounter a lot of problems while trying to do remote debugging
throuh Ethernet on ARM. I try to debug a C++ multithreaded program from
Cygwin using a cross-compilation toolchain I built myself (with gdb
6.4). I know this is a complex configuration but maybe somebody would be
able to orientate me a bit...

I compile my binaries statically as debugging with shared libraries
doesn't work (cf. my previous mail), but I have several other problems.

I use a timer which is generating a signal every 10 ms (SIGALRM). As
soon as timer_settime is called, there is a lot of network activity,
the gdb client seems to be busy (when I step) and debugging is unusable.
If i increase the period of this timer (to something like 50 ms) it is
OK. Would there be a means to still be able to debug my program with
the 10 ms period?

I have problems with breakpoints not taken into account, are there
known problems with some parts of my configuration (C++ or threads)?

Thanks in advance,

Milrith

Re: Problems with remote debugging on ARM

[Daniel Jacobowitz]

On Tue, May 16, 2006 at 06:08:20PM +0200, Milrith wrote:
> I use a timer which is generating a signal every 10 ms (SIGALRM). As
> soon as timer_settime is called, there is a lot of network activity,
> the gdb client seems to be busy (when I step) and debugging is unusable.
> If i increase the period of this timer (to something like 50 ms) it is
> OK. Would there be a means to still be able to debug my program with
> the 10 ms period?

Right now there is no way to do this.  I had a patch for it long ago,
but it wasn't very nice, and I never had time to go back to it.  You
could hack your GDB stub to ignore SIGALRM, in the same way that it
ignores certain threading-related signals (assuming you're using
gdbserver).

> I have problems with breakpoints not taken into account, are there
> known problems with some parts of my configuration (C++ or threads)?

Are they in constructors?  Google would be glad to tell you about the
problem, in that case.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems with remote debugging on ARM

[Mark Kettenis]

> Date: Tue, 16 May 2006 12:13:19 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Tue, May 16, 2006 at 06:08:20PM +0200, Milrith wrote:
> > I use a timer which is generating a signal every 10 ms (SIGALRM). As
> > soon as timer_settime is called, there is a lot of network activity,
> > the gdb client seems to be busy (when I step) and debugging is unusable.
> > If i increase the period of this timer (to something like 50 ms) it is
> > OK. Would there be a means to still be able to debug my program with
> > the 10 ms period?
> 
> Right now there is no way to do this.  I had a patch for it long ago,
> but it wasn't very nice, and I never had time to go back to it.  You
> could hack your GDB stub to ignore SIGALRM, in the same way that it
> ignores certain threading-related signals (assuming you're using
> gdbserver).

Actually it wouldn't be such a bad idea to extend the remote protocol
with something that allows GDB to specify the signals it's interested
in.  Ultimately you want this in the OS such that the stub (or a
native GDB) never even sees the signal.  Solaris and HP-UX have that
functionality.

Mark

Re: Problems with remote debugging on ARM

[Daniel Jacobowitz]

On Tue, May 16, 2006 at 08:18:05PM +0200, Mark Kettenis wrote:
> > Date: Tue, 16 May 2006 12:13:19 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > On Tue, May 16, 2006 at 06:08:20PM +0200, Milrith wrote:
> > > I use a timer which is generating a signal every 10 ms (SIGALRM). As
> > > soon as timer_settime is called, there is a lot of network activity,
> > > the gdb client seems to be busy (when I step) and debugging is unusable.
> > > If i increase the period of this timer (to something like 50 ms) it is
> > > OK. Would there be a means to still be able to debug my program with
> > > the 10 ms period?
> > 
> > Right now there is no way to do this.  I had a patch for it long ago,
> > but it wasn't very nice, and I never had time to go back to it.  You
> > could hack your GDB stub to ignore SIGALRM, in the same way that it
> > ignores certain threading-related signals (assuming you're using
> > gdbserver).
> 
> Actually it wouldn't be such a bad idea to extend the remote protocol
> with something that allows GDB to specify the signals it's interested
> in.  Ultimately you want this in the OS such that the stub (or a
> native GDB) never even sees the signal.  Solaris and HP-UX have that
> functionality.

That is precisely what I did :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems with remote debugging on ARM

[Milrith]

Le Tue, 16 May 2006 12:13:19 -0400 Daniel Jacobowitz <drow@false.org> a
écrit : 
> On Tue, May 16, 2006 at 06:08:20PM +0200, Milrith wrote:
> > I use a timer which is generating a signal every 10 ms (SIGALRM). As
> > soon as timer_settime is called, there is a lot of network activity,
> > the gdb client seems to be busy (when I step) and debugging is unusable.
> > If i increase the period of this timer (to something like 50 ms) it is
> > OK. Would there be a means to still be able to debug my program with
> > the 10 ms period?
> 
> Right now there is no way to do this.  I had a patch for it long ago,
> but it wasn't very nice, and I never had time to go back to it.  You
> could hack your GDB stub to ignore SIGALRM, in the same way that it
> ignores certain threading-related signals (assuming you're using
> gdbserver).

Yes, I am using gdbserver. Right now SIGALRM is treated as pass noprint
nostop. Would you have more details on how to do this hack? ;)

> > I have problems with breakpoints not taken into account, are there
> > known problems with some parts of my configuration (C++ or threads)?
> 
> Are they in constructors?  Google would be glad to tell you about the
> problem, in that case.

Unfortunately not, it can happen in normal methods. I am compiling
with -g and without any optimisation option.

Another little problem: I can't autocomplete method names with "::"
after the class names (Class::<tab> produces nothing), I suppose I am
missing a little something?

Thanks a lot,

Milrith

Re: Problems with remote debugging on ARM

[Daniel Jacobowitz]

On Tue, May 16, 2006 at 08:59:58PM +0200, Milrith wrote:
> Yes, I am using gdbserver. Right now SIGALRM is treated as pass noprint
> nostop. Would you have more details on how to do this hack? ;)

Look in gdbserver/linux-low.c for SIGRTMIN.

> > > I have problems with breakpoints not taken into account, are there
> > > known problems with some parts of my configuration (C++ or threads)?
> > 
> > Are they in constructors?  Google would be glad to tell you about the
> > problem, in that case.
> 
> Unfortunately not, it can happen in normal methods. I am compiling
> with -g and without any optimisation option.

Then we'll need you to submit a test case.

> Another little problem: I can't autocomplete method names with "::"
> after the class names (Class::<tab> produces nothing), I suppose I am
> missing a little something?

Try putting a single quote beforehand:

  print 'Class::<tab>

That'll work for now.

-- 
Daniel Jacobowitz
CodeSourcery