Mail Archives: djgpp/1998/08/06/19:08:41
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
- Raw text -