http://sourceware.org/bugzilla/show_bug.cgi?id=15389
Bug #: 15389
Summary: [avr] section '.note.gnu.build-id' allocated at
address zero
Product: binutils
Version: 2.23
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: jus...@jgottula.com
Classification: Unclassified
If gcc is configured with --enable-linker-build-id (as became the case for Arch
Linux's avr-gcc package recently when it was bumped to 4.8.0), then it passes
--build-id to the linker, and a '.note.gnu.build-id' section is allocated in
avr executables at address zero (where the interrupt vector table should be).
(See http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00332.html for more on this,
in the context of making --enable-linker-build-id the default behavior, which
apparently didn't happen.)
Strictly speaking, this is a configuration problem, so I will report it to my
distribution's package maintainers. However, I suggest that the linker scripts
should explicitly shove this section into a black hole, or at least handle it
similarly to the '.comment' or debug information sections (i.e., don't allocate
any memory for it). Peeking into the avr linker scripts, there doesn't seem to
be any any particular handling for it right now. ld's default behavior is
apparently just to drop sections it doesn't know about at address zero; and
then to dutifully shift the .text section (including the vector table, of
course) and all of the jump addresses over by 36 bytes so you can't just strip
out the problem section.
Steps to reproduce:
1. configure avr-gcc with --enable-linker-build-id
2. compile and link pretty much any avr program
3. run 'avr-objdump -h' or 'readelf -S'
(You could also use -Wl,--build-id when linking, but that would just be
idiotic.)
broken.elf: file format elf32-avr
Sections:
Idx Name Size VMA LMA File off Algn
0 .note.gnu.build-id 0024 0094 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .data 00800100 00ca 015e 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .text 00a6 0024 0024 00b8 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .stab 0738 0160 2**2
CONTENTS, READONLY, DEBUGGING
4 .stabstr 00a1 0898 2**0
CONTENTS, READONLY, DEBUGGING
5 .comment 0011 0939 2**0
CONTENTS, READONLY
Disassembly of section .note.gnu.build-id:
<.note.gnu.build-id>:
0: 04 00 .word 0x0004 ;
2: 00 00 nop
4: 14 00 .word 0x0014 ;
6: 00 00 nop
8: 03 00 .word 0x0003 ;
a: 00 00 nop
c: 47 4e sbcir20, 0xE7 ; 231
e: 55 00 .word 0x0055 ;
10: c5 c7 rjmp.+3978 ; 0xf9c <__stack+0x69d>
12: 03 77 andir16, 0x73 ; 115
14: fc 8d ldd r31, Y+28 ; 0x1c
16: c6 07 cpc r28, r22
18: 7f d8 rcall .-3842 ; 0xf118
<__eeprom_end+0xff7ef118>
1a: 61 e8 ldi r22, 0x81 ; 129
1c: 68 32 cpi r22, 0x28 ; 40
1e: 49 38 cpi r20, 0x89 ; 137
20: c5 69 ori r28, 0x95 ; 149
22: c4 85 ldd r28, Z+12 ; 0x0c
Disassembly of section .text:
0024 <__vectors>:
24: 0c 94 50 00 jmp 0xa0; 0xa0 <__ctors_end>
28: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
2c: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
30: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
34: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
38: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
3c: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
40: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
44: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
48: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
4c: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
50: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
54: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
58: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
5c: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
60: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
64: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
68: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
6c: 0c 94 5a 00 jmp 0xb4; 0xb4 <__bad_interrupt>
70: 0c 94 5a 00 jmp
