Date: Sat, 28 Jul 2001 12:42:23 -0400 Message-Id: <200107281642.MAA23764@delorie.com> X-Authentication-Warning: delorie.com: eliz set sender to eliz AT delorie DOT com using -f From: Eli Zaretskii To: n_abing AT ns DOT roxas-online DOT net DOT ph CC: djgpp-workers AT delorie DOT com In-reply-to: <3.0.1.32.20010521101259.0071c0d0@wingate> (n_abing AT ns DOT roxas-online DOT net DOT ph) Subject: Re: DJGPP core dumper References: <3 DOT 0 DOT 1 DOT 32 DOT 20010521101259 DOT 0071c0d0 AT wingate> 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 > Date: Mon, 21 May 2001 10:12:59 +0800 > From: "Nimrod A. Abing" > > I have just finished working on the core dumper for DJGPP. It's an almost > complete rewrite of George Foot's original core dumping code. The core > dumps are now in ELF format. I was thinking of attaching the (80K) package > to this message but I realized that I would be flamed to a crisp if I did > so. So here is the URL where you can check it out: > > http://www.geocities.com/n_abing/packages/djcore.zip Thanks! I looked into this, and it seems that the structure of the core file needs a few changes. First, you don't dump FP registers, which we need to debug floating-point programs. Next, the names of the sections that you've chosen seem to be different from what other platforms use in ELF core files; see bfd/elf.c in the Binutils or GDB distribution. (I'd like to be as compatible with other platforms as possible, to minimize DJGPP-specific code in both Binutils and GDB's core file support.) For example, the section with registers is called ".notes", not "regs", the sections with memory blocks are called ".mem", etc. Is there any reason for the particular choice of names in coredump.c? Finally, I'm not sure what to do with the environment and backtrace sections: GDB doesn't use them. Given that the stack is dumped as well, do we really need the backtrace? As for the environment, it's part of the normal address space, so why should we dump it once more, into a separate section? Btw, does anyone know what is the core_command member of elf_tdata structure (see bfd/elf.c in Binutils or in GDB) used for, and what should it hold? I'm guessing that it holds the program's argv[] array, but I cannot find any confirmation for this, as the structure of core files seems to be notoriously undocumented.