Peter N Lewis wrote,
#### #### FDE 0x2aea4 (OB 0x13fd60, fde_end 0x2affc) has zero length!Aborting. #### Abort
Fixed with gcc-3.3.
Geoff Keating wrote:
Adriaan van Os writes:
(4) compiling any .c source with -ggdb or -gdwarf-2 (instead of -gstabs or -g) produces the following output: Internal compiler error in default_no_named_section, at varasm.c:5305
Darwin doesn't really support dwarf2 at present.
Fixed with gcc-3.3, there is now a message "unknown or unsupported -g option".
Geoff Keating wrote:
Adriaan van Os writes:
Does anyone know what the status is of the following problems, encountered with gcc-3.2.1/3.2.2 on Darwin/Mac OS X ?
(1) trampolines crash (I have a patch to fix it)
(2) longjumps crash (I have a patch to fix it also)
(3) non-local goto's don't work, e.g.
These are all fixed in GCC 3.3.
Well, not quite. Longjump crashes and non-local goto crashes have been fixed, but trampoline crashes not. The gcc-3.2.x trampoline patch can be applied to gcc-3.3 and it fixes most trampoline crashes, but .....
./test_run: line 193: 766 Segmentation fault "$DIFF" testmake.tmp "$xo" TEST fproc.pas: failed
... running the testuite for fproc.pas takes a long time and fails. After a while the hardddisk starts to spin continuously, which might indicate that the system is allocating lots virtual memory (on a 1.25 GB Mac). After this, gpc1 crashes when compiling ANY .pas file, until a reboot. The typical backtrace looks like this:
Date/Time: 2003-05-18 03:11:07 +0200 OS Version: 10.2.4 (Build 6I32) Host: G4.local.
Command: gpc1 PID: 27979
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
Thread 0 Crashed: #0 0x0014ec68 in find_reloads (reload.c:4000) #1 0x0011bbe8 in reload_as_needed (reload1.c:3893) #2 0x00115388 in reload (reload1.c:1107) #3 0x001dca60 in global_alloc (global.c:583) #4 0x000991ec in rest_of_compilation (toplev.c:3304) #5 0x00007b58 in finish_routine (declarations.c:2436) #6 0x0002d27c in main_yyparse (parse.c:1739) #7 0x00097ce0 in compile_file (toplev.c:2134) #8 0x0009ce94 in do_compile (toplev.c:5370) #9 0x0009cf60 in toplev_main (toplev.c:5400) #10 0x00002700 in _start (crt.c:267) #11 0x00002580 in start
Maybe, virtual memory is corrupt after the fproc.pas testrun ??
Running the testsuite for fproc.pas with --longjmp-all-nonlocal-labels, results in a compiler error message:
TEST fproc.pas: /var/tmp//ccMu9pMb.s:unknown:Can't emit reloc {- symbol "LSJR11"} @ file address 800. /var/tmp//ccMu9pMb.s:unknown:Can't emit reloc {- symbol "LSJR11"} @ file address 796. /var/tmp//ccMu9pMb.s:unknown:Undefined local symbol L3$pb failed
Regards,
Adriaan van Os
Adriaan van Os wrote:
(1) trampolines crash (I have a patch to fix it)
(2) longjumps crash (I have a patch to fix it also)
(3) non-local goto's don't work, e.g.
These are all fixed in GCC 3.3.
Well, not quite. Longjump crashes and non-local goto crashes have been fixed, but trampoline crashes not. The gcc-3.2.x trampoline patch can be applied to gcc-3.3 and it fixes most trampoline crashes, but .....
I'm getting somewhat tired of this. Time and time again it's suggested to change to new gcc versions for these reasons (among others, of course), at least since gcc-2.8.1, and when it's done, it turns out the problems are still not really fixed (sometimes they're fixed on some platforms, sometimes they (re-)emerge on other platforms) ... :-(
BTW, are the bugs reproducible in C code?
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
(1) trampolines crash (I have a patch to fix it)
(2) longjumps crash (I have a patch to fix it also)
(3) non-local goto's don't work, e.g.
These are all fixed in GCC 3.3.
Well, not quite. Longjump crashes and non-local goto crashes have been fixed, but trampoline crashes not. The gcc-3.2.x trampoline patch can be applied to gcc-3.3 and it fixes most trampoline crashes, but .....
I'm getting somewhat tired of this. Time and time again it's suggested to change to new gcc versions for these reasons (among others, of course), at least since gcc-2.8.1, and when it's done, it turns out the problems are still not really fixed (sometimes they're fixed on some platforms, sometimes they (re-)emerge on other platforms) ... :-(
Yeah, they fix a few problems here and there and give us some fresh bugs in return to keep us busy. I hope it is not too discouraging.
BTW, are the bugs reproducible in C code?
I haven't checked so far, but found this (for gcc-3.3 with patched trampoline support):
1. without --longjmp-all-nonlocal-labels, fproc.pas runs "forever" until a shortage of virtual memory makes an end to it (and to Mac OS X as well). This explains the observations in my previous email.
2a. with --longjmp-all-nonlocal-labels, only fproc.pas and nlgpp2.pas fail: the assembler "can't emit reloc".
2b. this can be worked around by specifying -O2 instead of default -O3.
So, at least there is a work-around.
Regards,
Adriaan van Os
Does anyone know how I can link a GPC program to a framework (specifically, the OpenGL framework) under MacOS X? I tried {$L OpenGL}, etc., but library syntax does not work for frameworks...
GPC does not seem to use the OS X-provided 'ld' program, either, since adding -Xlinker "-framework OpenGL" to the GPC command line doesn't work (GPC's 'ld' complains about the unknown command line argument... should it be in quotes like that? is that doing it?)
Thank you.
===== ======= Frank D. Engel, Jr.
Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Frank D. Engel, Jr. wrote:
Does anyone know how I can link a GPC program to a framework (specifically, the OpenGL framework) under MacOS X? I tried {$L OpenGL}, etc., but library syntax does not work for frameworks...
GPC doesn't know about Mac OS X frameworks, but you can pass the needed information directly to the Apple "ld" linker with the -Wl option, e.g.
gpc --automake -Wl,-framework,OpenGL -o myprogram myprogram.pas gpc --automake -Wl,-framework,Carbon -o myprogram myprogram.pas gpc --automake -Wl,-framework,Carbon,-framework,OpenGL -o myprogram myprogram.pas
See <www.microbizz.nl/gpcfaq.html>
GPC does not seem to use the OS X-provided 'ld' program, either, since adding -Xlinker "-framework OpenGL" to the GPC command line doesn't work (GPC's 'ld' complains about the unknown command line argument... should it be in quotes like that? is that doing it?)
GPC does use "ld" on Mac OS X, however you must use -Wl instead of -Xlinker.
Dominique Louis Dominique@SavageSoftware.com.au is working on OpenGL interfaces for GPC and also on the OpenGL and SDL ports to Mac OS X. See previous messages on this list.
Regards,
Adriaan van Os
Thank you, that's a big help. I'll set up a makefile to automate the fixed linking process; no problem.
--- Adriaan van Os gpc@microbizz.nl wrote:
Frank D. Engel, Jr. wrote:
Does anyone know how I can link a GPC program to a framework (specifically, the OpenGL framework) under MacOS X? I tried {$L OpenGL}, etc., but library syntax does not work for frameworks...
GPC doesn't know about Mac OS X frameworks, but you can pass the needed information directly to the Apple "ld" linker with the -Wl option, e.g.
gpc --automake -Wl,-framework,OpenGL -o myprogram myprogram.pas gpc --automake -Wl,-framework,Carbon -o myprogram myprogram.pas gpc --automake -Wl,-framework,Carbon,-framework,OpenGL -o myprogram myprogram.pas
See <www.microbizz.nl/gpcfaq.html>
GPC does not seem to use the OS X-provided 'ld' program, either,
since
adding -Xlinker "-framework OpenGL" to the GPC command line doesn't work (GPC's 'ld' complains about the unknown command line
argument...
should it be in quotes like that? is that doing it?)
GPC does use "ld" on Mac OS X, however you must use -Wl instead of -Xlinker.
Dominique Louis Dominique@SavageSoftware.com.au is working on OpenGL interfaces for GPC and also on the OpenGL and SDL ports to Mac OS X. See previous messages on this list.
Regards,
Adriaan van Os
===== ======= Frank D. Engel, Jr.
Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Adriaan van Os wrote:
2b. this can be worked around by specifying -O2 instead of default -O3.
So, at least there is a work-around.
So it probably fails with inlined routines (that's the only difference between -O2 and -O3 unless this was changed in the latest versions). I had this suspicion earlier ...
Andrew Pinski wrote:
In 3.4 (do not know about 3.3): It looks like the register that is holding the pic address is overwritten in bar so when the jump happens the pic register now holds the pic for bar, not for main so it prints out some garbage. It looks like it should save and restore it in r30 like stack register is. A workaround in 3.4 for applications is to use -mdynamic-no-pic which will get rid of the pic code.
This makes me confident that it will be fixed (or at least that we are making progress).
I'm certain if it won't be solved in 3.5 or reemerges in 3.6, it will be finally fixed in 3.7 or at least a work-around for 3.8 provided in 3.9 which might work on some affected platforms in 4.0, others in 4.1 and in 4.2 they will start working on a real solution for 4.3 or 4.4 ... ;-)
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
(1) trampolines crash (I have a patch to fix it)
(2) longjumps crash (I have a patch to fix it also)
(3) non-local goto's don't work, e.g.
These are all fixed in GCC 3.3.
Well, not quite. Longjump crashes and non-local goto crashes have been fixed, but trampoline crashes not. The gcc-3.2.x trampoline patch can be applied to gcc-3.3 and it fixes most trampoline crashes, but .....
I'm getting somewhat tired of this. Time and time again it's suggested to change to new gcc versions for these reasons (among others, of course), at least since gcc-2.8.1, and when it's done, it turns out the problems are still not really fixed (sometimes they're fixed on some platforms, sometimes they (re-)emerge on other platforms) ... :-(
Trampoline crashes have now been fixed, for the gcc-3.3.1 branch and for mainline gcc 3.4, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10900.
Regards,
Adriaan van Os
Frank Heckenbach wrote:
<snip>
BTW, are the bugs reproducible in C code?
I don't have a C version of fproc.pas, but I tried the C code from a previous discussion instead:
extern int puts (const char *); extern void abort (void);
int main (void) { __label__ l1;
void foo (void) {
void bar (void) { puts ("goto l1"); goto l1; } bar ();}
foo (); abort (); l1: puts ("label l1"); return 0; }
The results on Mac OS X are incorrect, both with gcc-3.2.x and gcc-3.3. So, I reported this to the gcc gnats bug database. The reply was prompt:
Andrew Pinski wrote:
In 3.4 (do not know about 3.3): It looks like the register that is holding the pic address is overwritten in bar so when the jump happens the pic register now holds the pic for bar, not for main so it prints out some garbage. It looks like it should save and restore it in r30 like stack register is. A workaround in 3.4 for applications is to use -mdynamic-no-pic which will get rid of the pic code.
This makes me confident that it will be fixed (or at least that we are making progress).
Regards,
Adriaan van Os
-
Adriaan van Os -
Frank D. Engel, Jr. -
Frank Heckenbach