Re: [Patch, avr] Place progmem.data from avr-libc above other progmem

[Senthil Kumar Selvaraj <senthil_kumar dot selvaraj at atmel dot com>]

Alan Modra writes:

> On Wed, May 18, 2016 at 01:15:54PM +0530, Senthil Kumar Selvaraj wrote:
>> 
>> Nick Clifton writes:
>> 
>> > Hi Senthil,
>> >
>> >>   avr-libc's vfprint handling uses a lookup table located in flash
>> >>   if float format specifiers are involved. If user code also has
>> >>   lots of flash data (in section .progmem.data), then
>> >>   avr-libc's progmem data gets pushed beyond the 64 K word limit. The
>> >>   avr-libc code doesn't expect this to happen and vfprintf stops working correctly.
>> >
>> > Doesn't this indicate a problem with the linker - in that it does not
>> > report to the user that the code is broken and that accesses above the 64k
>> > limit are being made without use of the memx address space modifier ?
>> 
>> Do you mean reloc processing should have detected the overflow? In
>> this case, the offending value is loaded into two 8 bit regs, using the
>> lo8 and hi8 modifiers, resulting in R_AVR_LO8_LDI_NEG and
>> R_AVR_HI8_LDI_NEG relocs. I guess if there was a single reloc that
>> handled the value, we could have detected overflow, AVR has only 8 bit
>> registers though, so I can't see a way to do this. Am I missing something?
>
> The problem of values being split over multiple insns is not one that
> should affect AVR since you use RELA relocs.  The value ought to be
> available at each of the R_AVR_LO8_LDI_NEG and R_AVR_HI8_LDI_NEG
> relocs as the symbol value plus reloc addend.

Yes, but the > 64K symbol value itself is ok for each of those relocs - they
only write lower/next higher 8 bits of the value. The linker cannot
possibly know/tell that the value is big enough that it needs a extra
register load with a R_AVR_MS8_LDI reloc to load bits 24-31, can it?

Regards
Senthil