Message-Id: <3.0.1.32.20010425154212.006d5b7c@wingate>
X-Sender: n_abing#ns DOT roxas-online DOT net DOT ph AT wingate
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 25 Apr 2001 15:42:12 +0800
To: djgpp-workers AT delorie DOT com
From: "Nimrod A. Abing" <n_abing AT ns DOT roxas-online DOT net DOT ph>
Subject: Re: Fixed core dumper in dpmiexcp.c
Cc: sandmann AT clio DOT rice DOT edu, eliz AT is DOT elta DOT co DOT il, broeker AT physik DOT rwth-aachen DOT de
In-Reply-To: <Pine.SUN.3.91.1010425090111.22758D-100000@is>
References: <10104242208 DOT AA18766 AT clio DOT rice DOT edu>
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

Hello.

At 09:01 AM 04/25/2001 +0300, you wrote:
>
>On Tue, 24 Apr 2001, Charles Sandmann wrote:
>
>> This is also making the dump a much riskier thing - we've already had 
>> one exception and now we plan to potentially cause a bunch more while
>> dumping on an environment with unknown stability.
>> 
>> You may also dump several additional MB's of memory which don't belong to
>> you.
>> 
>> We really just need to add the memory block lengths someplace.  Maybe a
>> good incentive to re-write sbrk() in C :-)
>
>I agree that the Right Way would be to add this info to the memory
>handle structure.  The suggestion to longjmp out of the Page Fault was
>meant to provide a short-term band-aid to allow the development of the
>core file support to proceed with the current sbrk.
>
>Since the core file support will probably start as a separate library,
>we could supply a modified crt0.S there with an improved sbrk.

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. Second, we will get rid of that tricky block length calculation
code. Third, it would really make it a bit easier to debug memory related
problems from then on with the block size being recorded.

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. Right, now I'm moving on to rewriting the core file
format. The new format will be a modified version of the ELF core file format.

nimrod_a_abing
--------------

+========================================+
|  Home page: www.geocities.com/n_abing  |
+========================================+

"Ang batang makulit, pag lumaki ay pangit."
If you understand that phrase, i-email mo'ko. ;-)