Mail Archives: djgpp/1999/10/20/18:48:04
kriiid AT my-deja DOT com wrote:
>
> Eli Zaretskii wrote:
> >
> >On Sun, 17 Oct 1999 kriiid AT my-deja DOT com wrote:
> >
> >> Well, the first question is: when I get SIGSEGV there is written
> >> information about segments. What does limit section mean?
> >
> >It's one less than the segment size in bytes.
> >
> >> I thought
> >> this is size of segment. But now I don't think so, cause values like
> >> 0x8ffff are not really possible
> >
> >Why not? 0x8ffff is 589823 bytes: not too much for a typical DJGPP
> >program. Especially since 524288 bytes (512K) out of this amount is
> >the run-time stack, which is allocated at startup in its entirety.
>
> Well... I ment it's incredibly small. At least for me. So what if I'd
> like to allocate ie. 10 MB? Would djgpp extend this segment to ~11MB?
Yes.
> It look pretty inefficient (if it is done for every malloc).
Not really. It's a single DPMI call, which IIRC just has to update the
LDT and reload the selector. Also, it's only done in sbrk, when
malloc's pool runs out (it grows it in big chunks and reuses freed
memory), and sbrk is expensive anyway.
> >> the most essential function - allocating memory (501h). So I
> >> made program which just allocates some memory. I run it under
> windows.
> >> So, linear address is 05DAC000h. And now the funny part. Base address
> >> of DS/CS is 83046000h ;-). So now I've got a problem.
> >
> >Please explain why this is ``a problem''. I don't see any problem
> >here. You might base your judgement on some incorrect assumptions.
>
> May be.
> Well I try to access this memory using DS or CS. So the offset would
> have to be negative.
Nothing wrong with that. A pointer is an unsigned quantity. Any code
which depends on its "sign" is broken and should be fixed.
--
Nate Eldredge
neldredge AT hmc DOT edu
- Raw text -