Peter N Lewis a écrit:

Does --unit-destination-path work, or am I missing something:

zany:~/unix/c/testdir% ls -l total 8 drwxrwxr-x 2 peter staff 68 May 1 12:06 build -rw-rw-r-- 1 peter staff 104 May 1 12:05 testbuild.pas zany:~/unix/c/testdir% cat testbuild.pas unit testbuild;

interface

procedure testbuild;

implementation

procedure testbuild; begin end;

end. zany:~/unix/c/testdir% gpc -c --unit-destination-path=./build/ testbuild.pas zany:~/unix/c/testdir% ls -l total 24 drwxrwxr-x 2 peter staff 68 May 1 12:06 build -rw-rw-r-- 1 peter staff 354 May 1 12:06 testbuild.gpi -rw-rw-r-- 1 peter staff 1076 May 1 12:06 testbuild.o -rw-rw-r-- 1 peter staff 104 May 1 12:05 testbuild.pas zany:~/unix/c/testdir% ls -l build zany:~/unix/c/testdir%

It seems to ignore the --unit-destination-path setting, is there some different setting I'm missing?

You seem to want to compile pascal programs exactly as C programs, i.e. ignoring automake / autobuild (same about your other message about FDE). --unit-destination-path and the like work as expected with automake / autobuild. Now I suppose that the fact that this does not work in this case of separate compilations is a bug, remaining because this odd way of compiling is less well tested than the normal way (for pascal).

Maurice

Peter N Lewis wrote:

...

You seem to want to compile pascal programs exactly as C programs, i.e. ignoring automake / autobuild (same about your other message about FDE). --unit-destination-path and the like work as expected with automake / autobuild. Now I suppose that the fact that this does not work in this case of separate compilations is a bug, remaining because this odd way of compiling is less well tested than the normal way (for pascal).

It's not really an issue of "want to". I was originally compiling with automake, and am quite happy with that method. However the result of the gpc compile had the problem with the FDE I described. So then I started testing it in different ways, trying to figure out where the bug comes in to play.

First I tried the code that produces the problem converted entirely to C - no problem.

So then I tried the code in C, called from my Pascal code. Still has the problem.

So then I tried the code in C, called from my Pascal code, called from a trivial main in C with no Pascal initialization. No problem.

So then I tried the code in C, called from my Pascal code, called from a trivial main in Pascal with all the Pascal initialization. Problem reappears.

So then I tried the code in Pascal code, called from a trivial main in C with no Pascal initialization. No problem.

So the issue seems to be related to the initialization in Pascal. Since the error seems to be related to "unwinding the stack", even though whatever exception happens in the system code never actually gets back to me (when it is working in C), my best guess is that it is related to some sort of weird stack frame or something like that, and some exception handler is deciding to go looking up the stack and not finding an ending like it expects and crashing.

Oh well, perhaps this will help shed some light on the subject. Perhaps once I can use that --longjmp-all-nonlocal-labels flag that'll make a difference.

Does your program use any global labels? (I thought of them before I read this paragraph, and they might well be the issue.) However, then `--longjmp-all-nonlocal-labels' probably won't help since it will use longjmp for all nonlocal labels (including those from one subroutine to an outer containing routine, which don't seem to be at issue here), while it will make no difference with global labels.

What GPC does with them is basically like this C code. You might want to try if it reproduces the problem in C:

program Foo;

label 1;

procedure p; begin goto 1 end;

begin p; WriteLn ('not reached'); 1: WriteLn ('done') end.

#include <stdio.h> #include <setjmp.h>

jmp_buf j1;

static void p () { longjmp (j1, 1); }

int main () { if (setjmp (j1)) goto l1; p (); puts ("not reached"); l1: puts ("done"); return 0; }

The `setjmp' is probably the critical part (if it's that at all).

If that's not it, which part of the Pascal initialization (see include/gpc-in-c.h and demos/gpc_c_c.c) exactly triggers the problem. If it's the _p_initialize call, then it's the RTS initialization (skipping it indeed means you can't use many builtins), otherwise it's the automatically generated initialization code of the program.

Longer term my understanding was that the --automake and --autobuild were going to be deprecated in favour of real make, but perhaps I'm wrong on that.

Yes, they are. In the current automake, this problem would be very hard to fix (basically, it's all a big kludge, and problems such as this one are only the top of the iceberg while the rest is hidden with some tricks; with more effort it might be possible to hide this one as well, but at least I don't feel like doing it). With the new utility (gp), this problem should not exist.

Frank