[Patch,AVR]: Fix PR13697: Wrong symbols with --gc-sections
Georg-Johann Lay
avr@gjlay.de
Thu May 31 08:02:00 GMT 2012
Hans-Peter Nilsson schrieb:
> On Thu, 31 May 2012, Georg-Johann Lay wrote:
>> PR13697 appeared to be the easiest to fix so I proposed a patch.
>>
>> I am aware that the proposition is not optimal but it *works*.
>
> Did you understand the point that you're marking an input
> section when you should be marking the whole output section and
> that your solution will break if the whole code is compiled with
> -fdata-sections? (Assuming no assembly code adding anything to
> .data.)
I don't understand. If .data and .data.* are empty, and the code
compiled with -fdata-sections, the object is in .bss.varname instead
of in .bss. ar-nm still shows the right position with the patch
that adds PROVIDE(*(.data))
Also the code is as expected if .data and .bss* are empty but with
an object in .data.varname
>> And as long as there is so much resistance to restore reasonable
>> behavior (not move . backwards)
>
> What you see as resistance is really attempts at a resolution to
> help getting this fixed *without breaking expected behavior
> elsewhere*.
Ok. As I understood and from what Alan was saying, this PR is not
supposed to be a bug and just a self inflicted (gcc inflicted)
problem and that the test suite fails if the PR is fixed outside
the avr part.
>>> Alan pointed at two test-cases asserting the current behavior.
>> As I already said it's a bug to move the location counter backwards.
>
> The "backwards" view is apparently "just" an artefact of the
> map-file being done before the section being GC:ed away, which
> is admittedly also surprising.
Are you saying that there is even more bugs?
I.e. the mapfile is wrong or just plain misleading and the addresses
there are just some maybe correct or maybe incorrect addresses?
More confusing, the mapfile reports what was discarded so it's
aware of gc-ed sections:
Discarded input sections
.text 0x00000000 0x0 foo.o
.bss 0x00000000 0x0 foo.o
.data.saa 0x00000000 0x2 foo.o
More information about the Binutils
mailing list