Date: Thu, 15 Apr 1999 13:41:05 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Stack in djgpp
In-Reply-To: <m10X9m5-000S8aC@inti.gov.ar>
Message-ID: <Pine.SUN.3.91.990415134042.26213X-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


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! 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.

>     yyin = fopen(preOutName,"r");
>     unlink (preOutName); 
>     if (yyin == NULL) {
> 
> What's that?! he opens the file and unlinks it. Is that supposed to work in 
> UNIX? I mean: what the program will get from a file that was unliked?

It isn't actually removed until the handle is closed.  Note that,
amazingly enough, on NT this will work compiled with DJGPP!

> 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?

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.

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 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.