[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