Re: [avr-libc-dev] Possible hole in the assembler interrupt documentation

[Joerg Wunsch]

As Brendan Hanna wrote:

> It took me some time to realise that the vector would not be
> considered for linking unless its object file contained a dependency
> required by the main object file.

*Every* object (.o) file specified on the linker command-line is being
linked.  Only .a files, regardless of whether their names are
implicitly derived from a -l option, or explicitly specified as
libfoobar.a, are being searched in order to resolve undefined global
references (and those things not referenced there are not linked at
all).

What you guys are probably stumbling about is that you are using the
--gc-sections linker option.  Then, the linker does exactly what you
are asking it for: it drops every module that hasn't at least one
symbol being referenced from outside.

Here's a small example demonstrating the linker doesn't throw anything
away normally:

$ cat foo.c
int
main(void)
{
  return 42;
}
$ cat bar.s
.global __vector_8
__vector_8:
   nop
   reti
$ avr-gcc -mmcu=atmega8 -Os -o foo.elf foo.c bar.s
$ avr-objdump -d foo.elf

foo.elf:     file format elf32-avr


Disassembly of section .text:

00000000 <__vectors>:
   0:   12 c0           rjmp    .+36            ; 0x26 <__ctors_end>
   2:   19 c0           rjmp    .+50            ; 0x36 <__bad_interrupt>
   4:   18 c0           rjmp    .+48            ; 0x36 <__bad_interrupt>
   6:   17 c0           rjmp    .+46            ; 0x36 <__bad_interrupt>
   8:   16 c0           rjmp    .+44            ; 0x36 <__bad_interrupt>
   a:   15 c0           rjmp    .+42            ; 0x36 <__bad_interrupt>
   c:   14 c0           rjmp    .+40            ; 0x36 <__bad_interrupt>
   e:   13 c0           rjmp    .+38            ; 0x36 <__bad_interrupt>
  10:   16 c0           rjmp    .+44            ; 0x3e <__vector_8>
  12:   11 c0           rjmp    .+34            ; 0x36 <__bad_interrupt>
  14:   10 c0           rjmp    .+32            ; 0x36 <__bad_interrupt>
  16:   0f c0           rjmp    .+30            ; 0x36 <__bad_interrupt>
  18:   0e c0           rjmp    .+28            ; 0x36 <__bad_interrupt>
  1a:   0d c0           rjmp    .+26            ; 0x36 <__bad_interrupt>
  1c:   0c c0           rjmp    .+24            ; 0x36 <__bad_interrupt>
  1e:   0b c0           rjmp    .+22            ; 0x36 <__bad_interrupt>
  20:   0a c0           rjmp    .+20            ; 0x36 <__bad_interrupt>
  22:   09 c0           rjmp    .+18            ; 0x36 <__bad_interrupt>
  24:   08 c0           rjmp    .+16            ; 0x36 <__bad_interrupt>

00000026 <__ctors_end>:
  26:   11 24           eor     r1, r1
  28:   1f be           out     0x3f, r1        ; 63
  2a:   cf e5           ldi     r28, 0x5F       ; 95
  2c:   d4 e0           ldi     r29, 0x04       ; 4
  2e:   de bf           out     0x3e, r29       ; 62
  30:   cd bf           out     0x3d, r28       ; 61
  32:   02 d0           rcall   .+4             ; 0x38 <main>
  34:   06 c0           rjmp    .+12            ; 0x42 <_exit>

00000036 <__bad_interrupt>:
  36:   e4 cf           rjmp    .-56            ; 0x0 <__vectors>

00000038 <main>:
  38:   8a e2           ldi     r24, 0x2A       ; 42
  3a:   90 e0           ldi     r25, 0x00       ; 0
  3c:   08 95           ret

0000003e <__vector_8>:
  3e:   00 00           nop
  40:   18 95           reti

00000042 <_exit>:
  42:   f8 94           cli

00000044 <__stop_program>:
  44:   ff cf           rjmp    .-2             ; 0x44 <__stop_program>

The "nop" in the ISR is only there to demonstrate it's really the ISR
from bar.s that is being linked into the final object file.

(Besides, even with --gc-sections, the ISR remains there, because it
doesn't allocate an input section of its own.)
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)