Mail Archives: djgpp/2008/10/07/02:16:00
"Charles Sandmann" <cwsdpmi AT earthlink DOT net> wrote in message
news:MOadnT7eV5OCQHfVnZ2dnUVZ_g6dnZ2d AT earthlink DOT com...
> "Rod Pemberton" <do_not_have AT nohavenot DOT cmm> wrote in message
> news:gcbnih$6pq$1 AT aioe DOT org...
> >
> > I added some *inactive* code to a routine in a program I was working on
> > when
> > it began faulting in main(). I traced the problem to
> > __dpmi_set_segment_limit() from the fault info. The limit hadn't been
> > changed. __dpmi_set_segment_limit wasn't returning an error code
either.
> > The problem appears as __dpmi_set_segment_limit() working at first, but
> > then
> > the selector limit is being reset to its pre-call value. I.e., two
> > back-to-back calls to __dpmi_get_segment_limit return two different
> > values,
> > sometimes. The following C code represents the issue, but won't run as
is
> > since it doesn't align main() properly. The assembly code below has
been
> > adjusted (.space 0x7167) for the missing code and will need to be
compiled
> > as "gcc -o test.exe test.s". I've tested this under RM MS-DOS v7.10
> > w/DJGPP
> > v2.03 (GCC 3.4.1), DJGPP v2.04 (GCC 4.1.0), CWSDPMI v5 old and new,
> > CWSDPMI
> > three 6b versions, PMODETSR, etc. All combinations I've tried fail.
I'm
> > not sure why this only happens under these circumstances. Am I doing
> > something wrong? Any help?
>
> Under my old toolkit (v2.03) I can't reproduce the problem, compiling the
.s
> file. I
> suppose it's possible your toolchain makes a slightly different .exe ?
>
...? That's why I tried so many combinations. I was hoping that v2.04
wouldn't exhibit the issue... Do you think it could be an issue other than
DJGPP or dpmi host? Hmm, come to think of it, I didn't try it under
Windows...
> There is some code in crt0.S IIRC that messes with limits when dealing
with
> sbrk() expansion,
> it's possible that a malloc() call in the first printf() reset the limit.
Interesting, but the original code didn't have printf()'s... Those were
just to demonstrate the setting and restoring of the limit problem. At
first, I thought the issue was size related, since if you remove the .comm's
space, it'll work properly again. But, it also seems to require the
alignment or space prior to main.
> It's been a long time, and
> I have a hard time remembering details this obscure, but it's possible
that
> since the normal
> startup code calls malloc(), if you bypass the normal startup you might
need
> to reset the
> limit after the first call to sbrk(), or to use the crt0 flag to
> automatically make it big-wrap.
> At least it's someplace to start looking.
>
The original code did nothing special. But, I guess I could try those to
see if something changes the issue. It just had a bunch of "global" and
automatic space with two functions with medium sized switches... nothing
over ANSI or C99 limits.
> Have you tried stepping through it at an assembly instruction level with a
> debugger, looking
> for the DPMI segment limit change call?
>
No. In general, I don't use debuggers, so I'm not familiar. I'll probably
poke around the problem w/C and asm a bit more before I take that path. Big
leap...
Thanks,
Rod Pemberton
- Raw text -