Mail Archives: djgpp-workers/2001/06/13/09:47:09
On Wed, 13 Jun 2001, Andris Pavenis wrote:
> dxegen fails on object files built by gcc-3.0:
>
> After invoking ld, dxegen reads simbols and misinterprets some items
> as being unresolved external references
>
> andris AT hal:/disk2/cvs/djgpp/build/djgpp/src/libemu/src$ i586-pc-msdosdjgpp-nm --demangle emu387.o
> 000084a0 b .bss
> 000085f0 ? .comment
'?' indeed looks bad. Could this '.comment' be meant to be a section name,
rather than a symbol? I ask because of this observation, on Linux/x86
using gcc-2.95.2, binutils-2.9.1, and ELF binary format:
[oahu] ~/h1/anna $ size -A vektor.o
vektor.o :
section size addr
.text 1300 0
.data 0 0
.bss 120 0
.note 20 0
.stab 7968 0
.stabstr 18570 0
.comment 38 0
Total 28016
Note that '.comment' section. 'objdump --full-conts -j .comment' shows it
contains the gcc version string:
[oahu] ~/h1/anna $ objdump --full-contents -j '.comment' vektor.o
vektor.o: file format elf32-i386
Contents of section .comment:
0000 00474343 3a202847 4e552920 322e3935 .GCC: (GNU) 2.95
0010 2e322031 39393931 30323420 2872656c .2 19991024 (rel
0020 65617365 2900 ease).
I don't know how this should be handled, in a COFF-format file. What does
'objdump -x' say about this .o file? Here's what I get with binutils-2.9.1
on that Linux object file, for reference:
[oahu] ~/h1/anna $ objdump -x vektor.o | grep -i3 comment
CONTENTS, RELOC, READONLY, DEBUGGING
5 .stabstr 0000488a 00000000 00000000 00002494 2**0
CONTENTS, READONLY, DEBUGGING
6 .comment 00000026 00000000 00000000 00006d1e 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 vektor.c
--
00000000 l d .note 00000000
00000000 l d .stab 00000000
00000000 l d .stabstr 00000000
00000000 l d .comment 00000000
0000021c g F .text 00000025 dreivektor_laenge
00000244 g F .text 00000024 dreivektor_t_laenge
00000268 g F .text 0000002c viervektor_laenge
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -