Mail Archives: djgpp-workers/1999/04/15/17:10:36
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> On Tue, 13 Apr 1999, Salvador Eduardo Tropea (SET) wrote:
>
> > Looking in the djgpp configuration I saw why, they compute it:
> >
> > # define STACKBOTTOM ((ptr_t)((word) _stubinfo + _stubinfo->size \
> > + _stklen))
>
> Beware: this is from DJGPP v1.x! So other DJGPP-related stuff (if
> there is any) might be wrong as well.
Ugh!
> > Ugh! I think they really want to do it:
> >
> > # define STACKBOTTOM ((ptr_t)((word) __djgpp_stack_limit + _stklen))
>
> Yes, this is correct.
>
> But note that IIRC the memory configuration (the relative places of
> code, data, bss and stack) is different in DJGPP v2.x (DJ, am I
> right?), so you probably need to understand why do they want the
> STACKBOTTOM's value and how do they use it. If they use it for
> anything other than the stack limits, you should revise the code for
> v2.x.
I think they do something relative portable with the stack because the
configure file have this thing for at least 12 different systems, they need
to know the bottom and in what direction the stack grows. Is a grabage
collector.
I talked with the maintainer and he told me that he was planning to do this
change for the next release.
> > D:\DJ\BIN\LS.EXE: cannot open
> > Cannot exec Assembler: No such file or directory (ENOENT)
> >
> > I must investigate why. Any ideas? memory corruption?
>
> Which DJGPP version did you use? Was that 2.02 or 2.01?
Let me see what I have here ... 2.01
> The error message looks suspicially like the one which comes from the
> stub loader (it opens the .exe file to read the COFF header and
> data). In v2.01, this would happen when all 20 file handles were used
> up by the parent program. Since DOS only lets the first 20 handles
> be inherited by the child, the stub didn't have any free handles to
> open the .exe file.
Hmmm it sounds possible.
> In v2.02, the stub forcibly closes handles 19 and 18 (two, because
> some DPMI hosts need another handle to open a swap file when the stub
> switches to protected mode). So these problems shouldn't happen in
> v2.02. Unless you have found another bug ;-). Please try to find out
> why does it fail.
I'll compile the code at home this weekend (with 2.02) and I see what
happends. But isn't 100% needed because talking with the author I suggested
to use an approach much more similar to the one used by gcc/cpp/cc1/as/ld. He
currently have gcc and cc1 equivalents in one file and he saw the advantages
of spliting the file (like support more than one source in the command line
;-)
> > I was also forced to enlarge the stack, I guess that's because gc
> > accumulates tons of grabage in the stack before starting to collect it.
>
> Beware: it could be a sign of GC going berserk because they use the
> stack limits for something other than accessing the stack, like I said
> above. Maybe you should introduce some debugging printout into the
> program, to see what's going on.
But I don't know where, perhaps is just that the garbage collector puts *all*
the allocations in the stack and then the 256Kb are used for stack and heap.
I have this impression. The author told me that he almost doesn't call free.
Thanks, SET
------------------------------------ 0 --------------------------------
Visit my home page: http://welcome.to/SetSoft
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(5411) 4759 0013
- Raw text -