(.vectors+0x20): relocation truncated to fit: R_AVR_13_PCREL

Go To Last Post
45 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All - I'm getting a truncation error in the link step.
Can anyone tell me what exactly is happening here ?
What is the CRT attempting to place in
this vector and WHY is it getting truncated ?
This happened after I made some seemingly innocuous changes,
in a build that has been working forever.

Any explanation and work-around greatly appreciated !

Thanks in advance,
Best Regards, Dave

PS: ATmega128

PPS: This is NOT related to math libraries
as most times people see a truncation error...

Quote:
c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o: In function `__vector_default':
(.vectors+0x20): relocation truncated to fit: R_AVR_13_PCREL against symbol `__vector_8' defined in .text section in c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
make: *** [main.elf] Error 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do you invoke the linker?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's the abbreviated linker invocation:

avr-gcc -mmcu=atmega128 -I. -gstabs -DF_CPU=8000000UL  -I ./arch/avr -I ./include -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wa,-adhlns=general.o  -fno-exceptions -ffunction-sections  -fdata-sections  -fno-inline-small-functions -mcall-prologues -Wundef -fno-split-wide-types -Wstrict-prototypes -std=gnu99 -MD -MP -MF .dep/main.elf.d aaa.o bbbb.o ...... zzzz.o  main.o --output main.elf -Wl,-Map=main.map,--cref    -lm -Wl,--no-check-sections,-Tflarm_ld_gcc43.x		 -Wl,-relax,-gc-sections
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> -Tflarm_ld_gcc43.x

Are you sure that linker script is known to work correctly for an
AVR? Guessing from the name, I'd assume it's been designed for an
ARM target...

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is in flarm_ld_gcc43.x ?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Makefile file and LD script work for 14 of 15 different build variations for this product. Only one of 15 fails to link in this manner though it worked last week. I recently made minor changes which build correctly for all other variants. Clearly there is a size-related problem though I have ample room left in both flash and ram.

Can you tell me:
WHAT is the CRT attempting to place in this vector ?
WHY would it getting truncated ?
Any ideas how to work around this problem ?

Thanks in advance for the help,
Best Regards, Dave

PS: The LD script is certainly for AVR, not ARM !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DaveNadler wrote:
it worked last week
Then the changes made since last week must have broken something.

DaveNadler wrote:
Can you tell me:
Without a crystal ball... No.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Obviously the changes caused this link failure.
Which is why I posed the specific questions regarding the CRT implementation:

Can you tell me:
WHAT is the CRT attempting to place in this vector ?
WHY would it getting truncated ?
Any ideas how to work around this problem ?

Thanks in advance for the help,
Best Regards, Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DaveNadler wrote:
Obviously the changes caused this link failure.
Well, if that's obvious, then why don't you revert to the last week's state, then apply one change after other to find out which one was the culprit?

DaveNadler wrote:
WHAT is the CRT attempting to place in this vector ?

Nothing. (Okay, I did not need the crystal ball for this one).

CRT is startup code (including the interrupt vectors area) to be placed into AVR, so it cannot attempt to do anything during linking (which runs on PC). The linker attempts to fill the jump adresses in the vector table, according to actual position of the ISRs.

DaveNadler wrote:
WHY would it getting truncated ?
This is the part for which the crystal ball would be needed... or your cooperation.

DaveNadler wrote:
Which is why I posed the specific questions regarding the CRT implementation:

The crt's object file is avr-objdump-able, and the crt's sources are part of avr-libc, which is open source. If you are so assured that the problem is in CRT and refuse to answer our questions, why don't you have a look at the details yourself, then?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Clearly there is a size-related problem

Sure. That's what the error message says: something doesn't fit
into the 13-bit relocation space that has been requested by the
object file. IOW, you are trying to RJMP to a location that
cannot be reached that way.

Sorry, without seeing *all* of your toolchain-related stuff (C compiler
command lines, linker script), there won't be much further help.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The changes made last week only indirectly caused this size-related problem. I know where the problem surfaced, but the reason for the problem is size-related and not directly related the two lines of code I added...

So, I know that:
- CRT places default "something" into these vectors, and
- "something" is overflowing.

For example, is it a "something" relative branch instruction that overflows unless its target is within some magic distance ? What is the target ? How can this overflow be avoided ?

I was hoping someone knowledgeable about the mechanics of this particular CRT implementation could answer these basic questions. If nobody here has that level of knowledge, I'll go read the sources and figure it out...

Thanks in advance for any help,
Best Regards, Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
> Clearly there is a size-related problem

And I was told that size does not matter... ;-)

dl8dtl wrote:
Sure. That's what the error message says: something doesn't fit
into the 13-bit relocation space that has been requested by the
object file. IOW, you are trying to RJMP to a location that
cannot be reached that way.
But the mega's crt from WinAVR20100110, if untampered, uses JMPs (longjumps), which spans over the whole 64kW address space of ATM128 and far beyond.

OP wrote:
For example, is it a "something" relative branch instruction that overflows unless its target is within some magic distance ?
See above.

OP wrote:
What is the target ?
I told you already, the ISR (its entry point, a.k.a. beginning).

OP wrote:
How can this overflow be avoided ?
Don't try to be oversmart.

As the tools are set by default, the crt contains a lonjump to the ISR, and the ISR in .text is always within reach (otherwise .text would outflow off the allocated space).

However, the tools are fragile. If you do something "not common" (including custom linker scripts), expect troubles of all kinds. And, if you refuse to tell us what did you do, nobody can help you except yourself.

JW

Last Edited: Fri. Nov 12, 2010 - 01:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why would the CRT for the mega128 have RJMPs in its vector table?

Edit in fact it doesn't:

C:\WinAVR-20100110\avr\lib\avr5>avr-objdump -S crtm128.o

crtm128.o:     file format elf32-avr


Disassembly of section .text:

00000000 <__bad_interrupt>:
   0:   0c 94 00 00     jmp     0       ; 0x0 <__bad_interrupt>

Disassembly of section .vectors:

00000000 <__vectors>:
   0:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
   4:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
   8:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
   c:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  10:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  14:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  18:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  1c:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  20:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  24:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  28:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  2c:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  30:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  34:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  38:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  3c:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  40:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  44:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  48:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  4c:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  50:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  54:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  58:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  5c:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  60:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  64:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  68:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  6c:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  70:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  74:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  78:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  7c:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  80:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  84:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>
  88:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DaveNadler wrote:
The changes made last week only indirectly caused this size-related problem. I know where the problem surfaced, but the reason for the problem is size-related and not directly related the two lines of code I added...

How do you know? Show us those two lines.

Is it really only two lines? If you remove those two lines, does the problem go away?

And, if you are sure that it is indirect, then work out that indirection.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know because the other 14 of 15 builds work correctly with this change, as explained above. Yes, reverting to the prior version works, as explained above. The indirection is... size related.

This is a large project with proprietary components, and rather huge - so I can't just dump this stuff to you all.

Which components would be most helpful to zero in on the problem ? Linker script is pretty close to stock. CRT defaults as explained by CLawson should be long jumps. Linker command line is above. What would help ? Map file from successful build of another variant ? Tool chain is stock distribution 20010110; no mods to CRT or anything cute.

Thanks in advance for any and all help,
Best Regards, Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DaveNadler wrote:
Tool chain is stock distribution 20010110; no mods to CRT or anything cute.

And the added linker script?

You could also replace the offending huge code parts by some dummy content. You could also try to move the offending ISR into some other place, e.g. by reordering the object files. You could also avr-objdump the object containing the offending ISR and post the relevant snippet. Also, the linker often . And you could also post the mapfile of the compiling version, just make it clear in the post that it is not the problematic one. The linker also offers a --verbose option (I am not sure what does that do), and also sometimes the linker does produce the mapfile even if it does not actually link the file.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found the problem(s) - both in distribution 20100110 (ie avr51.x):
1) Linker script places progmem.data between default vector and vector table
2) default jump vectors are (erroneously) 13-bit relative and not longjump, though this seems to conflict with clawson's note above (didn't dig out how and why).

You can see this in map file below (note offsets near "13-bits" is magic 0x1000). Apparently default vector content points (via RJMP) to a default ISR in crt128. Moving .progmem.data after .text in the ld script fixes the problem (by loading crt128 code within 0x1000 of vectors).

Thanks guys for the help,
Best Regards, Dave

Quote:
.text 0x00000000 0xd8e6
*(.vectors)
.vectors 0x00000000 0x8c c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
0x00000000 __vectors
0x00000000 __vector_default
*(.vectors)
*(.progmem.gcc*)
.progmem.gcc_sw_table
0x0000008c 0x5c textcomm.o
.progmem.gcc_sw_table
0x000000e8 0x12 MasterFsm.o
.progmem.gcc_fplib
0x000000fa 0x2d c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51\libm.a(atan.o)
.progmem.gcc_fplib
0x00000127 0x1e c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51\libm.a(fp_sinus.o)
*(.progmem*)
.progmem.data 0x00000145 0x354 gps.o
.progmem.data 0x00000499 0xe4 usart.o
.progmem.data 0x0000057d 0x3f dataflash.o
.progmem.data 0x000005bc 0x31 rf.o
.progmem.data 0x000005ed 0x56 rf_app.o
.progmem.data 0x00000643 0x4f rf_diag.o
.progmem.data 0x00000692 0x8 nmea_utils.o
.progmem.data 0x0000069a 0x31 frametimer.o
.progmem.data 0x000006cb 0x3 binarycomm.o
.progmem.data 0x000006ce 0xf util.o
.progmem.data 0x000006dd 0x59c textcomm.o
.progmem.data 0x00000c79 0x65 tx_nmea.o
.progmem.data 0x00000cde 0x1e revision.o
0x00000cde hwKey
0x00000cea swKey
.progmem.data 0x00000cfc 0x38 ftime.o
.progmem.data 0x00000d34 0x3d alarm.o
.progmem.data 0x00000d71 0x4 arch/avr/rf_ll.o
.progmem.data 0x00000d75 0x159 collision.o
.progmem.data 0x00000ece 0xf7 main.o
0x00000fc6 . = ALIGN (0x2)
*fill* 0x00000fc5 0x1 00
revision.o(.progmem*)
0x00000fc6 __trampolines_start = .
*(.trampolines)
.trampolines 0x00000fc6 0x0 linker stubs
*(.trampolines*)
0x00000fc6 __trampolines_end = .
*(.jumptables)
*(.jumptables*)
*(.lowtext)
*(.lowtext*)
0x00000fc6 __ctors_start = .
*(.ctors)
0x00000fc6 __ctors_end = .
0x00000fc6 __dtors_start = .
*(.dtors)
0x00000fc6 __dtors_end = .
SORT(*)(.ctors)
SORT(*)(.dtors)
*(.init0)
.init0 0x00000fc6 0x0 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
0x00000fc6 __init
*(.init0)
*(.init1)
*(.init1)
*(.init2)
.init2 0x00000fc6 0xc c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
*(.init2)
*(.init3)
.init3 0x00000fd2 0x14 util.o
0x00000fd2 __fillRAM
*(.init3)
*(.init4)
.init4 0x00000fe6 0x1a c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
0x00000fe6 __do_copy_data
.init4 0x00001000 0x10 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/avr51\libgcc.a(_clear_bss.o)
0x00001000 __do_clear_bss
*(.init4)
*(.init5)
*(.init5)
*(.init6)
*(.init6)
*(.init7)
*(.init7)
*(.init8)
*(.init8)
*(.init9)
.init9 0x00001010 0x8 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
*(.init9)
*(.text)
.text 0x00001018 0x4 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
0x00001018 __vector_22
0x00001018 __vector_1
0x00001018 __vector_34
0x00001018 __vector_24
0x00001018 __vector_12
0x00001018 __bad_interrupt
0x00001018 __vector_6
0x00001018 __vector_31
0x00001018 __vector_3
0x00001018 __vector_23
0x00001018 __vector_25
0x00001018 __vector_11
0x00001018 __vector_13
0x00001018 __vector_17
0x00001018 __vector_19
0x00001018 __vector_7
0x00001018 __vector_5
0x00001018 __vector_33
0x00001018 __vector_4
0x00001018 __vector_9
0x00001018 __vector_21
0x00001018 __vector_29
0x00001018 __vector_8
0x00001018 __vector_14
0x00001018 __vector_10
0x00001018 __vector_16
0x0000101c . = ALIGN (0x2)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) are you talking about the home-brew linker script you used with -T or the standard mega128 one which is /winavr/avr/lib/ldscripts/avr51.x ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The standard script places .progmem.data such that with more than 0x1000 of PROGMEM data you will see this problem. This is now fixed in my version ;-) Any idea how come its using an RJMP despite what you noted above ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The standard script places .progmem.data such that with more than 0x1000 of PROGMEM data you will see this problem.

Err no. This builds for mega128 without error:

#include 
#include 

uint8_t data[0x1001] PROGMEM = { "Hello"};

int main(void) { 
	while(1);
} 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Weird. Can you post the segment of the map file that shows 0 to just past 0x1000 in text memory area as above ? Thanks !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
====================================================================================

.text           0x00000000     0x10e8
 *(.vectors)
 .vectors       0x00000000       0x8c c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
                0x00000000                __vectors
                0x00000000                __vector_default
 *(.vectors)
 *(.progmem.gcc*)
 *(.progmem*)
 .progmem.data  0x0000008c     0x1001 test.o
                0x0000008c                data
                0x0000108e                . = ALIGN (0x2)
 *fill*         0x0000108d        0x1 00
                0x0000108e                __trampolines_start = .
 *(.trampolines)
 .trampolines   0x0000108e        0x0 linker stubs
 *(.trampolines*)
                0x0000108e                __trampolines_end = .
 *(.jumptables)
 *(.jumptables*)
 *(.lowtext)
 *(.lowtext*)
                0x0000108e                __ctors_start = .
 *(.ctors)
                0x0000108e                __ctors_end = .
                0x0000108e                __dtors_start = .
 *(.dtors)
                0x0000108e                __dtors_end = .
 SORT(*)(.ctors)
 SORT(*)(.dtors)
 *(.init0)
 .init0         0x0000108e        0x0 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
                0x0000108e                __init
 *(.init0)
 *(.init1)
 *(.init1)
 *(.init2)
 .init2         0x0000108e        0xc c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
 *(.init2)
 *(.init3)
 *(.init3)
 *(.init4)
 .init4         0x0000109a       0x1a c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
                0x0000109a                __do_copy_data
 *(.init4)
 *(.init5)
 *(.init5)
 *(.init6)
 *(.init6)
 *(.init7)
 *(.init7)
 *(.init8)
 *(.init8)
 *(.init9)
 .init9         0x000010b4        0x8 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
 *(.init9)
 *(.text)
 .text          0x000010bc        0x4 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
                0x000010bc                __vector_22
                0x000010bc                __vector_28
                0x000010bc                __vector_1
                0x000010bc                __vector_32
                0x000010bc                __vector_34
                0x000010bc                __vector_24
                0x000010bc                __vector_12
                0x000010bc                __bad_interrupt
                0x000010bc                __vector_6
                0x000010bc                __vector_31
                0x000010bc                __vector_3
                0x000010bc                __vector_23
                0x000010bc                __vector_30
                0x000010bc                __vector_25
                0x000010bc                __vector_11
                0x000010bc                __vector_13
                0x000010bc                __vector_17
                0x000010bc                __vector_19
                0x000010bc                __vector_7
                0x000010bc                __vector_27
                0x000010bc                __vector_5
                0x000010bc                __vector_33
                0x000010bc                __vector_4
                0x000010bc                __vector_9
                0x000010bc                __vector_2
                0x000010bc                __vector_21
                0x000010bc                __vector_15
                0x000010bc                __vector_29
                0x000010bc                __vector_8
                0x000010bc                __vector_26
                0x000010bc                __vector_14
                0x000010bc                __vector_10
                0x000010bc                __vector_16
                0x000010bc                __vector_18
                0x000010bc                __vector_20
 .text          0x000010c0       0x14 test.o
                0x000010c0                main

BTW you weren't thinking that all those __vector_N entries were the vector table themselves were you? They are the DESTINATION of the vector table entries (all pointing to __bad_interrupt by default).

A disassembly of the start of the code shows the expected vector table in place and using JMPs:

D:\test>avr-objdump -S test.elf

test.elf:     file format elf32-avr


Disassembly of section .text:

00000000 <__vectors>:
       0:       0c 94 47 08     jmp     0x108e  ; 0x108e <__ctors_end>
       4:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
       8:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
       c:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      10:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      14:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      18:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      1c:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      20:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      24:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      28:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      2c:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      30:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      34:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      38:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      3c:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      40:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      44:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      48:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      4c:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      50:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      54:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      58:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      5c:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      60:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      64:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      68:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      6c:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      70:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      74:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      78:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      7c:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      80:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      84:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>
      88:       0c 94 5e 08     jmp     0x10bc  ; 0x10bc <__bad_interrupt>

0000008c :
      8c:       48 65 6c 6c 6f 00 00 00 00 00 00 00 00 00 00 00     Hello.......
....
        ...

0000108e <__ctors_end>:
    108e:       11 24           eor     r1, r1
SNIP!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ladies and gentlemen,

we might have now witnessed a genuine avr-gcc bug. More precisely, an avr-ld bug.

Tadaaaa.

I don't have WinAVR20100110 on this computer and don't intend to install it here, the '07 vintage here works well enough thank you, so, Cliff or anybody, would you please so kind and try that short snippet with:
1. -Wl,--relax, and
2. tweaking the array so that the vectors table falls exactly into 0x1018?

Meantime, Dave might try to link his top secret project *withouth* --relax.

Thanks.

Jan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

2. tweaking the array so that the vectors table falls exactly into 0x1018?

But the vector table is at 0x0002 (always - well always unless the whole of .text has been moved as one might do for a bootloader). Do you mean for the DESTINATION of the JMPs in the vector table to be at 0x1018 ?

I'll try (1) and report back though.

EDIT: tried --relax, no errors reported:

Linking: test.elf
avr-gcc -mmcu=atmega128 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -fun
signed-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes --save-temps -fverbose-asm -Wa,-adhlns=test.o  -std=gnu99 -MMD -MP -MF .dep/test.elf.d test.o --output test.elf -Wl,-Map=test.map,--cref     -lm -Wl,-q -Wl,--relax

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, yes, the dafult "bad isr" I meant. Try that please, together with --relax. Maybe also the other switches from Dave's commandline? The array should be 0xf52 or something.

Thanks

Jan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No joy:

 .text          0x00001018        0x4 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
                0x00001018                __vector_22
                0x00001018                __vector_28
                0x00001018                __vector_1
                0x00001018                __vector_32
                0x00001018                __vector_34
                0x00001018                __vector_24
                0x00001018                __vector_12
                0x00001018                __bad_interrupt
Compiling C: test.c
avr-gcc -c -mmcu=atmega128 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -
funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes --save
-temps -fverbose-asm -Wa,-adhlns=./test.lst  -std=gnu99 -MMD -MP -MF .dep/test.o
.d test.c -o test.o

Linking: test.elf
avr-gcc -mmcu=atmega128 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -fun
signed-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes --save-te
mps -fverbose-asm -Wa,-adhlns=test.o  -std=gnu99 -MMD -MP -MF .dep/test.elf.d te
st.o --output test.elf -Wl,-Map=test.map,--cref     -lm -Wl,-q -Wl,--relax

Creating load file for Flash: test.hex
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock test.elf test.hex

Creating load file for EEPROM: test.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
        --change-section-lma .eeprom=0 --no-change-warnings -O ihex test.elf tes
t.eep || exit 0

Creating Extended Listing: test.lss
avr-objdump -h -S -z test.elf > test.lss

(0xF62 in fact ;-))

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've got it!

Indeed, a --relax linker error, but reveals only when the math library (and I assume, any other library placing something into .progmem) is linked. Must be something with the order of linking and how the relaxation is performed.

#include 
#include 
#include 
#include 

uint8_t PROGMEM a[0xf3e] = {1};

volatile uint8_t b;
int main(void) {
  b = sin(a[b]);
}
C:\wek\!!! tmp\rozne pokusy>avr-gcc e.c -mmcu=atmega128 -Wl,-Map=e.map,--relax -
lm  -o e.elf
c:/program files/atmel/winavr/bin/../lib/gcc/avr/4.2.2/../../../../avr/lib/avr5/
crtm128.o: In function `__vectors':
../../../../crt1/gcrt1.S:60: relocation truncated to fit: R_AVR_13_PCREL against
 symbol `__vector_8' defined in .text section in c:/program files/atmel/winavr/b
in/../lib/gcc/avr/4.2.2/../../../../avr/lib/avr5/crtm128.o

C:\wek\!!! tmp\rozne pokusy>avr-gcc --version
avr-gcc (GCC) 4.2.2 (WinAVR 20071221)

Increasing the array by 4 increases the number of offending interrupt by 1. Increasing it by 2 compiles without error!

Cliff, or anybody, would you be so kind to try to reproduce with WinAVR20100110 and perhaps also with the "toolchain", beta or gamma or sigma or whichever.

Thanks,

Jan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jan,

Yup that fails in WinAVR20100110. I don't have the "AVR Total Balls up" to try that I'm afraid.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jan and CLawson you guys are awesome !
(Has a nice ring, no ?)
I will dink around with the sizes and/or -relax,
and try to relax myself as well.
Thanks Hugely !
Best Regards, Dave

PS: That's the 3rd toolchain bug I've tripped
on during the last 2 weeks, aarrrgggg....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

PS: That's the 3rd toolchain bug I've tripped
on during the last 2 weeks,

What were the other two?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was contemplating to submit a bug report to the binutils, but then found this in the list, tagged as NEW, dated April 2006. And it even says there is already a patch for it.

So much about the GNU processes.

J.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

PS: That's the 3rd toolchain bug I've tripped
on during the last 2 weeks,

What were the other two?

Erroneous handling of magic procmem attribute (bogus warning, incorrect code generation):
http://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jan and Cliff - How does one help ensure that these various bugs are addressed, and fixes tested and incorporated into next release ?

Thanks again for the help (who woulda thunk - just create some more PROGMEM constants and the linker will stop screwing up),

Best Regards, Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

How does one help ensure that these various bugs are addressed, and fixes tested and incorporated into next release

You get a copy of the source code, work out what the problem is then submit a patch with a new or to an existing bug report. The "gurus" then consider if the the solution is optimal and if so incorporate it in the next release. avr-gcc is a collaborative project.

Of course you could just wait for one of those gurus to take on the problem and develop a fix but there's no guarantees about how long that might take - they are just volunteers.

Submitted bugs are triaged and assigned severity levels - if a bug (like delay.h not working!) is given a high priority it will obviously be a candidate for fixing sooner than something like a spurious warning which could take years or may never be fixed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Submit to whom and how ? Seriously, especially since this error had a fix developed in 2006 and it seems to have gone nowhere.
Thanks,
Best Regards, Dave

PS: Searching for GCC AVR on the web shows multiple dead web sites where development stopped eons past ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As it says in the user manual:

Quote:
Note:
If you think you've found a bug, or have a suggestion for an improvement, either in this documentation or in the library itself, please use the bug tracker at https://savannah.nongnu.org/bugs... to ensure the issue won't be forgotten.

That's for AVR-LibC which is the set of libraries that ship with the compiler but I think it's OK to report actual suspected compiler bugs there too as they will be "pushed upstream" to the GCC project if it looks necessary.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DaveNadler wrote:
Submit to whom and how ? Seriously, especially since this error had a fix developed in 2006 and it seems to have gone nowhere.
You misunderstood me. It was not THIS bug, I was just disappointed by the fact that an old bug is still tagged as NEW.

Quote:
PS: Searching for GCC AVR on the web shows multiple dead web sites where development stopped eons past ;-)

The GNU toolset are a collection of relatively heterogeneous tools, held together by some strange cohesion. Remember, I told you earlier this day, it's fragile. Oh yes, the documentation as a whole s***s. Not that there is not enough of it, contrary; but it is messy, badly organized, abandoned, etc. Okay, there was no money put on it, I don't complain just state the quo.

You should submit a bug report appropriately to the part of the toolset. This one is related to the linker, avr-ld, which is the avr-targeted version of ld, which is part of binutils, for which the bug tracker is at http://sourceware.org/bugzilla/ .

The other bug you mentioned with C++ and progmem appears to be more gcc-specific, for which the bug tracker is at http://gcc.gnu.org/bugzilla/ .

The third major component would be avr-libc, for which you would be supposed to report to http://savannah.nongnu.org/bugs/... , but you would need to have a (free) account on the savannah server.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
... as they will be "pushed upstream" to the GCC project if it looks necessary.
... or not.

Alternatively, you might be yelled at for not providing a patch along with the bug report.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That note from the AVR-LibC manual says nothing about the reporter having to develop a fix so I think it'd be a bit rich if they moaned at people for not doing so! I'd have thought it better to get a fault logged into a tracking system however scant the details/solution than not at all.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jan and Cliff - email what you already did for concise test cases and I'll package it up and submit a bug report... I certainly don't have time to fix ld just now !
Thanks,
Best Regards, Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff wrote:

> You get a copy of the source code, work out what the problem
> is then submit a patch with a new or to an existing bug report.

Most importantly: you "stick to it". Start pestering people until the
bug will at least be assigned to someone. As long as it's just sitting
there as "new" or "unconfirmed", it's (unfortunately) very patiently
sitting there...

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This particular issue appears to be fixed now - see http://sourceware.org/PR13410

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
This particular issue appears to be fixed now - see http://sourceware.org/PR13410

JW


Thanks JW for bringing this to our attention. I see that the current downloadable toolchain is still from 20100110 at http://sourceforge.net/projects/winavr/files/. I am not familiar with the release cycle for these tools; when is the next release expected ?

Thanks again for the help,
Best Regards, Dave

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DaveNadler wrote:
I see that the current downloadable toolchain is still from 20100110 at http://sourceforge.net/projects/winavr/files/. I am not familiar with the release cycle for these tools; when is the next release expected?
WinAVR20100110 was announced as "last version" (see its release notes), as Eric Weddington, author of the "bundle" called WinAVR is Atmel employee for quite some time thus it appeared natural that internal Atmel development would replace the bundle builds. Since then, he announced at least once a continuation/revival, but it did not happen so far (and I have to add that I fully understand that).

Atmel's variants were released mostly as part of the various versions of AVRStudio5 and AtmelStudio6, but there were also standalone releases of the so called "AVRToolchain". I was trying to track these - work back through the links starting here if you are interested. These lack some of the utilities which came with WinAVR (as they are supposed to be used with the Studios).

There are also other toolchain builds like MHV's and of course SprinterSB's bleeding edge builds; and of notables are also Bingo's series of build scripts for Linux (see sticky at top of this subforum). These of course typically cover only the bare toolchain (compiler-assembler-linker + binutils assortment).

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh My. I guess we'll stick with the known 20100110 version for maintenance of legacy AVR products...
Thanks though,
Best Regards, Dave