Good GDB Version?

Good GDB Version?

[Kent Borg]

We are having problems with gdb.

Using gdb to talk to gdbserver over ethernet to our custom 405 board
we can run a trivial application, we can drop a breakpoint, land at
the breakpoint, look at variables and stuff--but trying to continue
doesn't move us forward.

When we revert to an old kernel we were using that originally came
from mvista.com's area51 (circa last spring) gdb/gdbserver works, so I
don't think it is an immediate operator error (but it maybe something
more subtle...).

I am wondering whether we have the right gdb.  Our current version is
5.0.  We also tried 5.0.93 (it didn't work either), but we worry that
our gdbserver wasn't matched with it.

What gdb/gdbserver do y'all use?  (Where did you get it??)  When
co-worker Peter last built gdbserver for us he couldn't find
maintained sources and had to do some cobbling to make it work.  (That
was at 5.0, a few months ago.)

Have there maybe been signifcant changes to ptrace that we need to
know about here?  Is ptrace is working order currently?

One more detail, these symptoms are on a kernel brought up to date
with a linuxppc devel rsync from yesterday afternoon.

Suggestions?


Thanks,

-kb, the Kent who is writing this on behalf of a colleague who isn't
on the list.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Good GDB Version?

[Kent Borg]

On Fri, Dec 14, 2001 at 01:53:12PM -0500, I wrote:
> We are having problems with gdb.

And, though we have not gotten to the bottom of it, we seem to have a
hardware problem.  But a bizarre one.

We download our code, watch the kernel boot, get an sh prompt.  Fire
up ethernet, do an NFS mount of a directory on the development
machine.  Launch gdbserver on a trivial helloworld program, attach
from gdb on the development machine (using ethernet).

All that works.  It would seem to suggest the hardware is working,
right?  Well, that's what we thought.

Tell gdb to continue.  Immediately get a SIGTRAP.  And further
attempts to use gdb act strange, such as after hitting a breakpoint
not being able to continue from there.

Re-downloading the boot ROM does not fix it.

Swap in a different logic card, do all the above, and everything is
the same except that initial SIGTRAP doesn't happen and breakpoints
can be continued from and everything seems completely happy.  That
board works.

Swap in the physical boot ROM from the good board to the bad board and
the problem stays with the bad board.  Both boards have the same rev
of the 405GP.

How could we have crafted a custom board that can recognize that gdb
is running an only malfunction then?  I didn't know hardware could be
so clever.

My only guess is something hanging around the JTAG (or is it BDM?)
debug port might be funny--for the debug port has privileged access to
some of the same internal hardware that gdb uses.  Maybe a hardware
fault there could cause spurious SIGTRAPs--or maybe something is
fritzed inside the 405's debug hardware.

Strange.

-kb

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/