Mail Archives: djgpp-workers/1999/04/14/18:07:43
Salvador Eduardo Tropea (SET) wrote:
>
> Hi:
>
> Today I tried to compile SDCC[1] (a Free ware , retargettable, optimizing
> ANSI-C compiler for MCUs) with djgpp. So I uncompressed with LFNs, started
> bash and played a bit (the package work with Linux and more or less with
> Cygwin). It compiled ok (with some warnings) but doesn't work very well.
> One of the things that I don't know if about a library it includes. This
> library is called gc[2] (A garbage collector for C and C++) and have djgpp as
> one of the targets, but I think they did some stuff wrong.
> The gc library needs some low level information about the stack pointer
> (looks like the allocations uses the stack, I hate garbage collectors and
> this looks very tricky). The test program passed but the compiler died with
> an error about the stack growing in the reverse direction ;-))
> Looking in the djgpp configuration I saw why, they compute it:
>
> # define STACKBOTTOM ((ptr_t)((word) _stubinfo + _stubinfo->size \
> + _stklen))
>
> Ugh! I think they really want to do it:
>
> # define STACKBOTTOM ((ptr_t)((word) __djgpp_stack_limit + _stklen))
>
> What do you think?
> Anyways, after changing it both (test and compiler) passed. But my doubt is
> if that's safe, can the program play with this value?
Well, do_faulting_finish_message uses this code:
err("App stack: ["); itox(__djgpp_stack_limit+_stklen, 8);
err(".."); itox(__djgpp_stack_limit, 8);
So it certainly looks reasonable.
> I also needed to patch a couple of things related to:
>
> 1) fork(), the author uses fork just because the command is there, he forks,
> one thread execs another program and the other waits! why? isn't that the
> same that spawn(P_WAIT,... ?
Unix doesn't have spawn. fork/exec/wait is the standard (and most
portable) way of doing this on Unix.
But if `system' is appropriate, by all means use that. It's ANSI.
> 2) The author also does it:
>
> 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?
Yes.
> I mean: what the program will get from a file that was unliked?
Nothing different.
On Unix, a file and its name are not necessarily in one-to-one
correspondence. A file can have an arbitrary number of names (links).
`unlink' removes a link, making the file inaccessible by that name, but
doesn't necessarily delete the file itself. This is done only when no
links remain, and no process is holding the file open.
Sometime when you have access to a Unix system, try:
yes >/tmp/foo & # Write continuously to /tmp/foo, in the
background.
rm /tmp/foo # unlink it
Then do `df' several times, and notice that your free disk space is
still dropping.
Now `kill %yes' and watch it magically reappear.
Note: Filling up the disk may break things; don't try this on your
employer's web server!
In this case, it's probably done so that the file will get deleted even
if the program crashes. In such an event, the OS would close the file,
then notice that it had no links and no processes using it, and would
physically delete it from the disk.
This would also have the property that no other process could possibly
open the file (except possibly the program's children), so you might see
it done for security reasons.
> Even after modifying (1) and (2) I can't get the program running :-(. The
> compiler generates the assembler output, but when spawns the assembler
> program I get: (I changed the name of the linker to ls, just for testing):
>
> D:\DJ\BIN\LS.EXE: cannot open
> Cannot exec Assembler: No such file or directory (ENOENT)
>
> I must investigate why. Any ideas? memory corruption?
I suppose d:\dj\bin\ls.exe exists?
Other than that, you could single-step the spawn call and see where it
fails.
HTH
--
Nate Eldredge
nate AT cartsys DOT com
- Raw text -