Date:	Thu, 6 Aug 1998 10:00:49 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
cc:	djgpp AT delorie DOT com
Subject:	Re: help! SIGILL?!?
In-Reply-To:	<199808060134.CAA16926@sable.ox.ac.uk>
Message-ID:	<Pine.SUN.3.91.980806100030.15220L-100000@is>
MIME-Version:	1.0

On Thu, 6 Aug 1998, George Foot wrote:

> but the only reason for the traceback to stop after a single 
> line would be for the content of the stack to be bogus.

That's not the only case: the content of the exception state structure
could be scrogged as well.

> Whatever EIP 
> is, it is just printed as the first item on the traceback.  I don't 
> think it affects the rest of the traceback at all.

I think it could affect it indirectly through the exception structure.

> I can't help feeling that it would be better to get GDB to
> understand the core dumps.  I don't know anything about GDB though.

GDB already knows about core files.  You just need to make your core
files fit into the existing GDB code.

> I'm also not sure that it would benefit much from being part of djgpp
> directly.  It seems to work quite well as a separate module.

You could add it to the src/debug tree in DJGPP sources, so it will be
put into libdbg.a.  Then whoever needs it would link with -ldbg.

> That said, a few changes to the djgpp library code would make it 
> possible for this to work better in a number of ways.  At the moment 
> there's no way to find out the sizes of the DPMI memory blocks, 
> unless the DPMI server supports __dpmi_get_memory_block_size_and_base 
> -- but I haven't found a DPMI server that supports this yet.

Are you sure?  Did you look at src/libc/dpmi/helper/mapmem.c in the
library sources?  It seems that it does some of the things that you
need.

- Raw text -