This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Patch, avr] Place progmem.data from avr-libc above other progmem
- From: Nick Clifton <nickc at redhat dot com>
- To: Senthil Kumar Selvaraj <senthil_kumar dot selvaraj at atmel dot com>
- Cc: binutils at sourceware dot org, Denis Chertykov <chertykov at gmail dot com>
- Date: Wed, 18 May 2016 10:36:21 +0100
- Subject: Re: [Patch, avr] Place progmem.data from avr-libc above other progmem
- Authentication-results: sourceware.org; auth=none
- References: <87oa8832kx dot fsf at atmel dot com> <fb734ee9-5592-716c-787d-4e9036863477 at redhat dot com> <87eg8z3j2l dot fsf at atmel dot com>
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?
It could be that, or some other mechanism. I am just saying that if there is
the potential for the linker to produce a broken binary because the user has
failed to annotate their memory references correctly then it would be a good
idea for the linker to generate an error message. Assuming that it possible
of course. I am not familiar with the AVR architecture, so I do not know what
is and is not do-able.
Cheers
Nick