Problems with remote debugging on ARM

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

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

> Date: Tue, 16 May 2006 12:13:19 -0400
> From: Daniel Jacobowitz <drowfalse.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

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 <drowfalse.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

Le Tue, 16 May 2006 12:13:19 -0400 Daniel Jacobowitz
<drowfalse.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

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