Re: remote connection crash, was frame theory

[Jim Blandy <jimb@red-bean.com>]

On 1/26/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Jan 26, 2006 at 03:42:02PM -0800, Jim Blandy wrote:
> > On 1/26/06, NZG <ngustavson@emacinc.com> wrote:
> > > On Thursday 26 January 2006 4:44 pm, Daniel Jacobowitz wrote:
> > > > On Thu, Jan 26, 2006 at 11:40:07PM +0100, Mark Kettenis wrote:
> > > > > To me, it looks like you're connecting to a buggy stub.
> > > >
> > > > He's connecting to basically a standard gdbserver, poised at
> > > > the first instruction of the program.  Memory has garbage
> > > > and/or is invalid - no MMU so reading from garbage memory
> > > > is a bit more serious than is typical for GDB.
> > > righto, it crashes the remote kernel and sends my host into an infinite loop
> > > in gdb.
> > >
> > > > The best thing here would be, if the stub can find out from
> > > > the kernel what constitutes "valid" RAM, to refuse reads to
> > > > it.  Then ignore the ugliness when you type backtrace and
> > > > don't have a stack yet - it's not real surprising that doesn't
> > > > work!
> >
> > The PC is valid at this point, right?  If there were clean Dwarf CFI
> > for the entry point, marking it as the oldest frame, would that calm
> > GDB down?  That could be another approach.
>
> Yes, that should generally work.

For reference, I added Dwarf CFI for the _start function in crt0.s for
the m32c libgloss port:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/libgloss/m32c/crt0.S?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=src

You'll need to look at the CFI section of the Dwarf spec to adapt this
to your processor.  (Fortunately, Dwarf CFI is pretty independent of
the rest of Dwarf, so don't be discouraged by the overall size of the
spec.)