Mail Archives: djgpp/2012/04/25/13:39:32
Am Sonntag, 22. April 2012 schrieb Eli Zaretskii:
> > From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
> > Date: Sat, 21 Apr 2012 23:30:13 +0200
> > Cc: djgpp AT delorie DOT com
> >
> > gcc -c -Demacs -DHAVE_CONFIG_H -I. -I. -O2 -gcoff -save-temps xdisp.c
> > xdisp.s: Assembler messages:
> > xdisp.s:31360: Error: CFI instruction used without previous .cfi_startproc
> > xdisp.s:31362: Error: CFI instruction used without previous .cfi_startproc
> > xdisp.s:31363: Error: CFI instruction used without previous .cfi_startproc
> > xdisp.s:31365: Error: CFI instruction used without previous .cfi_startproc
> > xdisp.s:31366: Error: CFI instruction used without previous .cfi_startproc
> > xdisp.s:31370: Error: .cfi_endproc without corresponding .cfi_startproc
> > xdisp.s: Error: open CFI at the end of file; missing .cfi_endproc directive
>
> I guess COFF debug info generation by GCC bit-rotted. I suggest to
> file a bug report with the GCC bug-tracker.
>
> > Is there any reason why -gcoff is used to compile the code in /src directory?
>
> Yes. If you use DWARF-2, the resulting binary of Emacs after dumping
> segfaults when invoked. Or at least that's what happened last time I
> tried (which was a long time ago, admittedly).
>
Only for the record. I have compiled em2302s with different compilers.
I have only tested with DJGPP 2.04, bnu222br3 and gdb74br2.
compiling debuging
COFF DWARF COFF DWARF
+--------+--------+--------+--------+
gcc344 | OK | OK | OK | KO |
+--------+--------+--------+--------+
gcc400 | OK | OK | OK | KO |
gcc401 | OK | OK | OK | KO |
+--------+--------+--------+--------+
gcc410 | OK | OK | OK | KO |
gcc411 | OK | OK | OK | KO |
gcc412 | OK | OK | OK | KO |
+--------+--------+--------+--------+
gcc420 | OK | OK | OK | KO |
gcc421 | OK | OK | OK | KO |
gcc422 | OK | OK | OK | KO |
gcc423 | OK | OK | OK | KO |
+--------+--------+--------+--------+
gcc430 | OK | OK | OK | KO |
gcc431 | OK | OK | OK | KO |
gcc432 | OK | OK | OK | KO |
+--------+--------+--------+--------+
gcc441 | OK | OK | OK | KO |
gcc442 | OK | OK | OK | KO |
gcc444 | OK | OK | OK | KO |
gcc445 | OK | OK | OK | KO |
+--------+--------+--------+--------+
gcc452 | KO1 | KO1 | KO | KO |
gcc453 | KO1 | KO1 | KO | KO |
+--------+--------+--------+--------+
gcc461 | KO2 | KO1 | -- | -- |
gcc462 | KO2 | KO1 | -- | -- |
gcc463 | KO2 | KO1 | -- | -- |
+--------+--------+--------+--------+
gcc470 | KO2 | KO1 | -- | -- |
+--------+--------+--------+--------+
KO1 compiling means that temacs is build but the dump process does not work.
Neither emacs.exe nor a stack trace are produced.
KO2 compiling means that the compiler produces brocken assembler output due
to brocken COFF debug info support. No temacs is produced at all.
KO debuging means that the produced binary seems to have no line information
so that it is not possible to set break points and to step trough the binary.
Regards,
Juan M. Guerrero
- Raw text -