🚀 go-pugleaf

Disclaimer: this applies to the port of gdb to mips machines; I
haven't verified this behavior on other machines.

If a process bombs because the pc is bogus (like a jump to a NULL
pointer), gdb may get a memory read error when it sets up its frame
chain. gdb completely gives up at this point and throws to top level.

I've noticed this in trying to look at a core file that resulted from
such a crash. The value of the pc (0x1) doesn't exist as an address in
the core file, so gdb gives up and doesn't seem to allow one to look
at the core file at all.

So I've got two questions:

1) Is there a way to force gdb to examine the core file anyway?

2) Is anyone doing any work on getting gdb to do something useful in
the presence of an invalid pc? There are several good ways to recover.
On mips (and other RISC machines) a register holds the return pointer
for subroutine calls; this usually holds a valid address and is a good
place to start (dbx on SGI Iris 4d machines does this). On other
machines, one might scan the machine stack for a value that looks like
a program address or at worst use the starting address of the program
as the pc.

I don't want to duplicate work, but if no one else is working on this
I may write the code myself.

Tim Moore                     moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters