This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch,AVR]: Fix PR13697: Wrong symbols with --gc-sections

Tristan Gingold wrote:
> On May 30, 2012, at 6:17 AM, Alan Modra wrote:
>> On Tue, May 29, 2012 at 03:37:45PM -0400, Hans-Peter Nilsson wrote:
>>> On Tue, 29 May 2012, Georg-Johann Lay wrote:
>>>> At the start of .bss the location counter is moved backwards!
>>>> I still think this is a linker bug.
>>> Well yes, but the point was that the bug is not the linker
>>> script's lack of KEEP.
>> Whether or not this is a bug depends on how you think zero size
>> discarded output sections should be treated.  One extreme is to treat
>> discarded output sections as if they do not exist, so address,
>> alignment, mapping to segments, and probably other things I've
>> forgotten, are ignored and so do not affect following sections.  The
>> other extreme is to just remove them from the section headers, but
>> otherwise apply all their attributes.  Johann seems to want this
>> latter behaviour judging from his comment about optimisation.  The
>> trouble is that whatever ld does, someone will be unhappy.  For
>> instance, if we always apply alignment then you can get holes in the
>> memory image caused by unused sections.  Some will view that as a
>> "bug".

upgraded to you new version, but with no avail:
The data in .bss is still inside I/O area no matter if symbols are
defined in like:

    __foo1 = .;
    __foo2 = __data_start;
    PROVIDE (__foo3 = __data_start);

These symbols have the expected addresses (just as without the patch)
but the /subsequent/ data is still misplaced.

I still prefer correct code over optimized but wrong code.

Until there is a proper fix, could the KEEP solution be applied?

Other solutions like providing a linker script for each architecture
would mean to change GCC and completely restructure multilib layout.

> Why not adding a KEEP attribute on sections, ie like:
> .data : KEEP ...
> {
>  ...
> }

Isn't this the same like the proposed KEEP(*(.data)) from above?
If not: what is the difference?
And what is the right syntax?
This always exits with a syntax error and dosc don't mention KEEP at all:

> to many everyone happy ?
> Tristan.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]