Date: Wed, 25 Apr 2001 12:01:05 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Nimrod A. Abing" <n_abing AT ns DOT roxas-online DOT net DOT ph>
cc: djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu,
        broeker AT physik DOT rwth-aachen DOT de
Subject: Re: Fixed core dumper in dpmiexcp.c
In-Reply-To: <3.0.1.32.20010425154212.006d5b7c@wingate>
Message-ID: <Pine.SUN.3.91.1010425115735.24299F-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Wed, 25 Apr 2001, Nimrod A. Abing wrote:

> Yup, an improved sbrk -- one that records the block lengths would be a
> better solution. One reason, the core dumper will just use the
> __djgpp_memory_handle_list directly instead of using its own internal data
> structure.

Feel free to modify sbrk, if you like.  It will be a welcome change, I 
think.

> As for making the core file support a separate library, the original
> version did just that however it chained into the existing exception
> handler -- i.e. it chained into the default djgpp exception handler so
> after the core dump it would print the cftb. In this case, the register
> values especially eip differed in the core dump and in the cftb output, the
> register values in the core dump are wrong. I merged the core dumper code
> with dpmiexcp.c to correct this and added some variables to let the user
> tweak the core dumper.

I was thinking along the lines of providing the modified dpmiexcp.c (and 
maybe a modified crt0.S) in this separate library.  If you say something 
like "gcc foo.c -lcore", these modified versions are linked in instead of 
the stock ones in libc.a.