Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
On Mac OS X, stabs debugging info is the default, but out of curiosity I tried the other formats:
-gdwarf-2 dummy.pas:0: Internal compiler error in default_no_named_section, at varasm.c:5305
I'm not sure if dwarf2 is supported at all on this target (does it work in C?), or if I can do anything about it, but maybe you can provide a stack trace (in gdb, set a breakpoint, and when it gets there do `i s').
The fsf-gcc-3.2.1 compiler produces precisely the same error on Mac OS X ! So, it must be a gcc problem, although the source code at varasm.c:5305 tries to suggest otherwise:
void default_no_named_section (name, flags) const char *name ATTRIBUTE_UNUSED; unsigned int flags ATTRIBUTE_UNUSED; { /* Some object formats don't support named sections at all. The front-end should already have flagged this as an error. */ abort (); }
It is most likely a gcc problem, but as I said, a stack trace could perhaps tell me something about where it comes from.
When running gcc ...
(gdb) backtrace #0 default_no_named_section (name=0x28fcd8 ".debug_abbrev", flags=1024) at ../../gpc-20030323/gcc/varasm.c:5305
OK, as far as I understand it, dwarf2 debug info is stored in "named sections" in the assembler code (dwarf2out.c:3679). Some object formats support names sections, and some don't (default_no_named_section and the following 3 functions in varasm.c).
The Darwin backend claims to support dwarf2 (config/darwin.h:128), but doesn't set TARGET_ASM_NAMED_SECTION (either by omission, or correctly because its object format really doesn't support named sections).
So I think the error is in the Darwin backend. It should either set TARGET_ASM_NAMED_SECTION (if that's possible) or not set DWARF2_DEBUGGING_INFO.
Feel free to forward this mail to whomever it may concern.
Frank