parseObjDump fails when a relocation record points to a section
Hi, Current git fails to compile for me with: Building ld scripts (version "pre-0.6.2-20101219_191912-tata") Traceback (most recent call last): File "./tools/layoutrom.py", line 573, in <module> main() File "./tools/layoutrom.py", line 554, in main info16 = parseObjDump(infile16, '16') File "./tools/layoutrom.py", line 538, in parseObjDump reloc.symbol = symbols[symbolname] KeyError: '.rodata.__func__.2140' make: *** [out/romlayout16.lds] Error 1 The interesting parts of the associated objdump are: Sections: Idx Name Size VMA LMA File off Algn [...] 110 .rodata.__func__.2140 0000000a 00000000 00000000 000304fc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA [...] SYMBOL TABLE: [...] 00000000 l O .rodata.__func__.2140 0000000a __func__.2140 [...] 00000000 l d .rodata.__func__.2140 00000000 [...] RELOCATION RECORDS FOR [.debug_info]: OFFSET TYPE VALUE [...] 0001419f R_386_32 .rodata.__func__.2140 [...] So the relocation record points to the section and not a symbol, and the script dies. What can I do? Best, OG. PS: binutils-2.20.1 GNU objdump 2.15.92.0.2 20040927 gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2) (on x86_64)
On Sun, Dec 19, 2010 at 07:25:42PM +0100, Olivier Galibert wrote:
Current git fails to compile for me with: [...] The interesting parts of the associated objdump are:
Sections: Idx Name Size VMA LMA File off Algn [...] 110 .rodata.__func__.2140 0000000a 00000000 00000000 000304fc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA [...] SYMBOL TABLE: [...] 00000000 l O .rodata.__func__.2140 0000000a __func__.2140 [...] 00000000 l d .rodata.__func__.2140 00000000 [...] RELOCATION RECORDS FOR [.debug_info]: OFFSET TYPE VALUE [...] 0001419f R_386_32 .rodata.__func__.2140
That's odd. It shouldn't even have tried to parse the debug sections. Can you email me a tar file of the build after running "make clean; make"? -Kevin
On Sun, Dec 19, 2010 at 05:53:44PM -0500, Kevin O'Connor wrote:
That's odd. It shouldn't even have tried to parse the debug sections. Can you email me a tar file of the build after running "make clean; make"?
Sure, http://dspnet.fr/~galibert/seabios-work.tar.bz2 Despite the name, it's a pristine clone. OG.
On Sun, Dec 19, 2010 at 05:53:44PM -0500, Kevin O'Connor wrote:
On Sun, Dec 19, 2010 at 07:25:42PM +0100, Olivier Galibert wrote:
Current git fails to compile for me with: [...] The interesting parts of the associated objdump are:
Sections: Idx Name Size VMA LMA File off Algn [...] 110 .rodata.__func__.2140 0000000a 00000000 00000000 000304fc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA [...] SYMBOL TABLE: [...] 00000000 l O .rodata.__func__.2140 0000000a __func__.2140 [...] 00000000 l d .rodata.__func__.2140 00000000 [...] RELOCATION RECORDS FOR [.debug_info]: OFFSET TYPE VALUE [...] 0001419f R_386_32 .rodata.__func__.2140
That's odd. It shouldn't even have tried to parse the debug sections. Can you email me a tar file of the build after running "make clean; make"?
I checked further, it's not crashing on the debug section but on a following one: RELOCATION RECORDS FOR [.text.handle_02]: OFFSET TYPE VALUE 00000002 R_386_32 .rodata.__func__.2140 OG.
On Mon, Dec 20, 2010 at 08:28:54PM +0100, Olivier Galibert wrote:
On Sun, Dec 19, 2010 at 05:53:44PM -0500, Kevin O'Connor wrote:
On Sun, Dec 19, 2010 at 07:25:42PM +0100, Olivier Galibert wrote:
Current git fails to compile for me with: [...] The interesting parts of the associated objdump are:
Sections: Idx Name Size VMA LMA File off Algn [...] 110 .rodata.__func__.2140 0000000a 00000000 00000000 000304fc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA [...] SYMBOL TABLE: [...] 00000000 l O .rodata.__func__.2140 0000000a __func__.2140 [...] 00000000 l d .rodata.__func__.2140 00000000 [...] RELOCATION RECORDS FOR [.debug_info]: OFFSET TYPE VALUE [...] 0001419f R_386_32 .rodata.__func__.2140
That's odd. It shouldn't even have tried to parse the debug sections. Can you email me a tar file of the build after running "make clean; make"?
I checked further, it's not crashing on the debug section but on a following one: RELOCATION RECORDS FOR [.text.handle_02]: OFFSET TYPE VALUE 00000002 R_386_32 .rodata.__func__.2140
Yeah - more binutils oddities. Does the patch below help? What distro did you find this binutils on? -Kevin --- a/tools/layoutrom.py +++ b/tools/layoutrom.py @@ -532,7 +532,16 @@ def parseObjDump(file, fileid): reloc.offset = int(off, 16) reloc.type = type reloc.symbolname = symbolname - reloc.symbol = symbols[symbolname] + reloc.symbol = symbols.get(symbolname) + if reloc.symbol is None: + # Some binutils give section name instead of a + # symbol - create a dummy symbol. + reloc.symbol = symbol = Symbol() + symbol.size = 0 + symbol.offset = 0 + symbol.name = symbolname + symbol.section = sectionmap.get(symbolname) + symbols[symbolname] = symbol relocsection.relocs.append(reloc) except ValueError: pass
On Mon, Dec 20, 2010 at 10:13:20PM -0500, Kevin O'Connor wrote:
Yeah - more binutils oddities. Does the patch below help? What distro did you find this binutils on?
It compiles with it, thanks. I'll tell you if it fails in testing. I use gentoo, which means compile-from-source. It's binutils-2.20.1.tar.bz2 with the patches from binutils-2.20.1-patches-1.1.tar.bz2 which you can find both in a gentoo distfiles near you. ftp://ftp.proxad.fr/pub/Distributions_Linux/Gentoo/distfiles/ in my case. Best, OG.
participants (2)
-
Kevin O'Connor -
Olivier Galibert