Message-Id: <199808092219.XAA13675@sable.ox.ac.uk>
Comments: Authenticated sender is <mert0407 AT sable DOT ox DOT ac DOT uk>
From: George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date: Sun, 9 Aug 1998 23:18:06 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: help! SIGILL?!?
Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk
CC: djgpp AT delorie DOT com
Precedence: bulk

On  9 Aug 98 at 13:10, Eli Zaretskii wrote:

> On Fri, 7 Aug 1998, George Foot wrote:
> 
> > I think someone once said that it would be complicated, because of the 
> > way the program's memory is divided into separate blocks.
> 
> That was me ;-).  But it seems that debugging core files doesn't really
> require to reconstruct the memory layout.  This layout is important if 
> the debuggee could call `sbrk'.  Since it cannot do that in post-mortem
> debugging, all you need to care about is that you can find a variable or
> an instruction given their address.

Yes, I thought it was you. :)  I looked at GDB's source briefly, and
the impression I got was that all that needs changing significantly
is the BFD library.  I'll work on it when I have time; I don't at the
moment though.

> > The impression I got was that GDB likes to load the core as 
> > a single continuous block, in which case we might get very large core 
> > files if the program's DPMI memory blocks aren't tightly packed.
> 
> Even if this is true, it just means that a program which wants to support 
> core dumps needs to be built with unixy sbrk algorithm: not an impossible 
> requirement IMHO.

I think it depends upon what you're debugging.  For example, Allegro
will force the non-move sbrk algorithm to be used.

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk