Good GDB Version?

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/

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/