Message-Id: <199808062307.AAA13027@sable.ox.ac.uk> Comments: Authenticated sender is From: George Foot To: Eli Zaretskii Date: Fri, 7 Aug 1998 00:06:47 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: help! SIGILL?!? Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk CC: djgpp AT delorie DOT com Precedence: bulk On 6 Aug 98 at 10:00, Eli Zaretskii wrote: > On Thu, 6 Aug 1998, George Foot wrote: > > > but the only reason for the traceback to stop after a single > > line would be for the content of the stack to be bogus. > > That's not the only case: the content of the exception state structure > could be scrogged as well. Really? Hmm, I thought that was set up either during processing of the signal using setjmp (in which case EIP ought to be valid [and small]) or at the same time as the exception occurs, and no user code is executed between that point and the creation of the traceback. To be honest though I don't really understand where the struct comes from if it's not faked. > > I can't help feeling that it would be better to get GDB to > > understand the core dumps. I don't know anything about GDB though. > > GDB already knows about core files. You just need to make your core > files fit into the existing GDB code. Yes, but I think someone once said that it would be complicated, because of the way the program's memory is divided into separate blocks. The impression I got was that GDB likes to load the core as a single continuous block, in which case we might get very large core files if the program's DPMI memory blocks aren't tightly packed. I'll have a look at it sometime, but I've never used GDB so I'm not in an ideal position to modify it. > > I'm also not sure that it would benefit much from being part of djgpp > > directly. It seems to work quite well as a separate module. > > You could add it to the src/debug tree in DJGPP sources, so it will be > put into libdbg.a. Then whoever needs it would link with -ldbg. Oh, OK. I thought libdbg was more of a set of routines for debuggers to use than a set of routines for normal programs to use. > > That said, a few changes to the djgpp library code would make it > > possible for this to work better in a number of ways. At the moment > > there's no way to find out the sizes of the DPMI memory blocks, > > unless the DPMI server supports __dpmi_get_memory_block_size_and_base > > -- but I haven't found a DPMI server that supports this yet. > > Are you sure? Did you look at src/libc/dpmi/helper/mapmem.c in the > library sources? It seems that it does some of the things that you > need. I hadn't looked at that, but it's doing roughly what I'm doing at the moment. Presently I make a list of base addresses of blocks, then try to determine their sizes by first assuming that they're tightly packed, with each block ending where the next begins (using sbrk(0) IIRC as the end of the last block) and then using the DPMI call I mentioned above to try to get the real sizes of the blocks. If the calls succeed, their values override the maximum possible values as previously calculated. The problem is that if the DPMI function is not available and the blocks are widely spaced, the reported size of the blocks will be much larger than the real size. For example: block 2, base=0x1000000, size=0x00010000 block 3, base=0x2000000 then the apparent size of block 2 is 0x10000000. I'm not sure whether or not this can occur in practice; I looked quite closely at the library source code (in particular, the code for sbrk) and didn't see any guarrantee that the blocks will be tightly packed (i.e. that in the example above block 3's base would be 0x10010000). If this can be guarranteed then there is no problem at all. The change that would be needed to provide this information would be either adding it to struct __djgpp_sbrk_handle, or storing the sizes separately if altering that struct could cause problems. -- george DOT foot AT merton DOT oxford DOT ac DOT uk