Date: Fri, 30 Mar 2001 14:29:21 +0400 From: egor duda X-Mailer: The Bat! (v1.45) Personal Organization: deo X-Priority: 3 (Normal) Message-ID: <12289438285.20010330142921@logos-m.ru> To: Eli Zaretskii CC: gdb AT sources DOT redhat DOT com, Eli Zaretskii , Charles Sandmann , Subject: Re: Adding support for core files to DJGPP In-reply-To: <200103300906.EAA18026@indy.delorie.com> References: <200103300906 DOT EAA18026 AT indy DOT delorie DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Hi! Friday, 30 March, 2001 Eli Zaretskii eliz AT delorie DOT com wrote: EZ> We are trying to add support for core files to the DJGPP port of GDB. EZ> However, the available documentation which describes what needs to be EZ> done is, at best, scanty ;-) So I wonder if someone here can help. EZ> Producing a core file in a format already supported by BFD is not EZ> easy, because under the default algorithm used by DJGPP's sbrk the EZ> program's address space may be non-contiguous. This is due to EZ> peculiarities of various DPMI hosts used on specific platforms, EZ> most notably Windows, and the fact that the DPMI spec doesn't provide EZ> any way for the program to specify where in memory will the program's EZ> code and data be put; you just request a chunk of memory of the size EZ> you need and get a buffer wherever the DPMI host wants it to be. The EZ> same problem also makes it next to impossible to reproduce the exact EZ> way the program's address space was layed out after reading the core EZ> file. i think that cygwin in this account is similar to djgpp, so, i think, cygwin's way to produce and analyze core dumps may be used in djgpp EZ> (If this is not clear enough, and if someone is interested, I can tell EZ> more details.) EZ> We already have a prototype version of code which writes to a disk EZ> file the program's memory image and some additional information, such EZ> as the general-purpose registers, segment selectors, etc. But the EZ> format of the core file is not something BFD can understand. EZ> For these reasons, we would try first to explore the possibility of EZ> using a custom core file format, instead of going through BFD. EZ> However, I cannot find any real documentation of the API used by GDB EZ> for accessing core files. I'd expect GDB to need a few functions to EZ> read the core file (or, perhaps, its specific portions), find out the EZ> values in registers at the point of crash, what was the signal that EZ> aborted the program, etc. Where can I look for some info about this? EZ> If someone has experience in providing such kind of core file support, EZ> could they please post any advice that could be useful, and/or point EZ> to any docs and code that could be of use to us? i implemented core files for cygwin some time ago. the core file is created in elf format. all committed pages in process address space are written to .mem sections (adjacent pages go to one section), and additional data such as register values for all threads and names of all dlls mapped into process's address space are written into .note sections of NT_WIN32PSTATUS type. here, too, memory regions allocated for process may be non-continuous, and their addresses are not known beforehand. what gdb needs to do when he saw such core file is to open it via normal bfd calls, scan it for additional info in .note sections and map all .mem sections. the latter is done automatically, iirc, you should only make section name to start from ".mem/" for details, see bfd/elf.c (elfcore_grok_win32pstatus) -- stub to process .note sections in cygwin elf core file. winsup/utils/dumper.cc -- utility to create core file. gdb/win32-nat.c -- functions to process elf core file. actually most of this code is dealing with dlls mapped into dumped process address space -- to reduce size of core file their code sections are not written to core file, but instead only their path is written, so gdb will map their code sections from dll itself not from core file. i don't think that djgpp will need such functionality, so code will be somewhat simpler. Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19