Message-Id: <3.0.1.32.20010329134717.006b3a78@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: Thu, 29 Mar 2001 13:47:17 +0800
To: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
From: "Nimrod A. Abing" <n_abing AT ns DOT roxas-online DOT net DOT ph>
Subject: Re: dpmiexcp.c with core dumping
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <10103290510.AA17496@clio.rice.edu>
References: <3 DOT 0 DOT 1 DOT 32 DOT 20010328133149 DOT 006aec58 AT wingate>
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

At 11:10 PM 03/28/2001 -0600, you wrote:
>> Attached to this message is dpmiexcp.c modified to provide core dumping for
>> DJGPP programs. 
>
>(And DJ Delorie asked:)
>
>>How difficult would it be for the module to create a COFF format core
>>file, similar to what bfd/gdb already knows how to read?  That would
>>make it a lot easier to add core support to gdb later.
>
>I would also like to see a "standard" format, but there is a problem
>when we use the non-move sbrk().  Since Windows just loves returning 
>non-contiguous memory blocks all over the place (sometimes below the
>base address, which makes it look like a 4Gb address space) the core
>files are huge unless they are dumped in pieces.  This also makes it
>a real pain to process the core files also...

That explains why SIGSEGVs occured when dumping core from a program running
in a Win9x DOS box. The problem disappears when I run it under plain DOS
with CWSDPMI R5 (fffffix) and I get a properly dumped core file.

As for this "standard" format for core files, does anyone know where I can
find any docs for this? Even murky ones will do :-)

>I believe we could use the standard core format if we used the unixy-sbrk,
>but some extension is needed with the default sbrk().
>
>Or at least this is what I remember from a few years ago.  
>
>I'm actually happy to see work moving in this area - if someone looks at
>an old source for dpmiexcp I had some comments in there about core stuff

Is this it?
[...]
/* This routine must call exit() or jump changing stacks.  This routine is
   the basis for traceback generation, core creation, signal handling. */
void
__djgpp_exception_processor(void)
{
  int sig;
  
  sig = except_to_sig(__djgpp_exception_state->__signum);
  raise(sig);
  if(__djgpp_exception_state->__signum >= EXCEPTION_COUNT) /* Not exception
so continue OK */
    longjmp(__djgpp_exception_state, __djgpp_exception_state->__eax);
  /* User handler did not exit or longjmp, we must exit */
  err("Cannot continue from exception, ");
  print_signal_name(sig);
  do_faulting_finish_message(0);
}
[...]

If so, please tell me as much as you can about this. TIA.

One issue has been bothering me lately though, what about memory paged to
disk?

Best regards.

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

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

"Tinimbang ka ngunit kulang."
If you understand that phrase, i-email mo'ko. ;-)