[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #11 from David Li --- No problem with this as long as ld does not throw away note sections. thanks, -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446
--- Comment #10 from Nick Clifton ---
Hi Xinliangli,
> However I do think ld's behavior is
> not correct here. Should linker first decide if some sections are 'root'
> sections that should not be throw away and then decide if other sections
> should
> be GCed? Here linker first prunes the references and then is forced to discard
> section not because it should do so, but to make the link succeed.
Yes, but... the linker has not been told that the UNREF section is a root
section. If the test had used a linker script that specified that the UNREF
section should be kept[1] then the linker would have acted differently. It
would keep the UNREF section and g0 variable and everything would have worked
as expected.
Since however the UNREF section is an orphan section, the linker has more
latitude in what it can do. The LD linker decides that since the section has
relocations against it, and since these relocations refers to symbols which are
otherwise unused, then it makes sense to discard the section. You disagree
with this decision. I don't. But since there are several
available workarounds, and, as far as I know, it is not breaking real programs,
I do not plan to make any changes to the linker.
Cheers
Nick
[1] ie:
UNREF : { KEEP (*(UNREF)) }
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
Hi Xinliangli,
However I do think ld's behavior is
not correct here. Should linker first decide if some sections are 'root'
sections that should not be throw away and then decide if other sections should
be GCed? Here linker first prunes the references and then is forced to discard
section not because it should do so, but to make the link succeed.
Yes, but... the linker has not been told that the UNREF section is a root
section. If the test had used a linker script that specified that the UNREF
section should be kept[1] then the linker would have acted differently. It
would keep the UNREF section and g0 variable and everything would have worked
as expected.
Since however the UNREF section is an orphan section, the linker has more latitude in what it can do. The LD linker decides that since the section has relocations against it, and since these relocations refers to symbols which are otherwise unused, then it makes sense to discard the section. You disagree with this decision. I don't. But since there are several
available workarounds, and, as far as I know, it is not breaking real programs, I do not plan to make any changes to the linker.
Cheers
Nick
[1] ie:
UNREF : { KEEP (*(UNREF)) }
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #8 from Nick Clifton --- Hi David, Right - I think that I have got a handle on what it going on here. So what happens is this - g0 is a data symbol. In your case it is a common symbol, but it could equally be an ordinary data symbol too. Either way it is present in unref2.o. When the linker is invoked it sees that g0 is only ever referenced from UNREF an unallocated, unloaded section. So it has two choices. It can either a) decide that since UNREF will never be loaded that there is no need to allocate space for g0 in the runtime image or b) decide that g0 is referenced by something it must have space allocated to it and so it is put into the .bss section. The LD linker makes choice a), GOLD makes choice b). The results of garbage collection are then affected by this choice. With LD, since g0 is being discarded, it has to also discard UNREF, as otherwise you would be left with a section in the executable that references an object that no longer exists. With GOLD, since g0 exists, the UNREF section can be kept. (By default unallocated sections are kept since they do not contribute anything to the runtime memory usage of the executable, and they can be presumed to contain something useful). So that is the situation. Nothing has changed with 2.26 or the mainline sources by the way - they still behave in the way that you saw. To be honest however I do not think that there is a bug here to be fixed. The fact that an unallocated, unloaded, non-debug section references data in the executable is very strange. Or at least pretty unusual. There are ways around the problem - by making the unref'ed section a note section or a fake debug section - but as far as I can see the only real issue is that LD and GOLD differ in their handling of the situation. I don't believe that there is a standard that specifies what should happen in this situation, so either choice is valid. You pick the linker that gives you the behaviour you want. Does that satisfy you ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #9 from David Li --- (In reply to Nick Clifton from comment #8) > Hi David, > > Right - I think that I have got a handle on what it going on here. > > So what happens is this - g0 is a data symbol. In your case it is a > common symbol, but it could equally be an ordinary data symbol too. Either > way it is present in unref2.o. > > When the linker is invoked it sees that g0 is only ever referenced from > UNREF an unallocated, unloaded section. So it has two choices. It can > either a) decide that since UNREF will never be loaded that there is no need > to allocate space for g0 in the runtime image or b) decide that g0 is > referenced by something it must have space allocated to it and so it is put > into the .bss section. The LD linker makes choice a), GOLD makes choice b). > > The results of garbage collection are then affected by this choice. With > LD, since g0 is being discarded, it has to also discard UNREF, as otherwise > you would be left with a section in the executable that references an object > that no longer exists. With GOLD, since g0 exists, the UNREF section can be > kept. (By default unallocated sections are kept since they do not > contribute anything to the runtime memory usage of the executable, and they > can be presumed to contain something useful). > > So that is the situation. Nothing has changed with 2.26 or the mainline > sources by the way - they still behave in the way that you saw. > > To be honest however I do not think that there is a bug here to be fixed. > The fact that an unallocated, unloaded, non-debug section references data in > the executable is very strange. Or at least pretty unusual. There are ways > around the problem - by making the unref'ed section a note section or a fake > debug section - but as far as I can see the only real issue is that LD and > GOLD differ in their handling of the situation. I don't believe that there > is a standard that specifies what should happen in this situation, so either > choice is valid. You pick the linker that gives you the behaviour you want. > > Does that satisfy you ? > > Cheers > Nick Nick, thanks for the detailed explanation. However I do think ld's behavior is not correct here. Should linker first decide if some sections are 'root' sections that should not be throw away and then decide if other sections should be GCed? Here linker first prunes the references and then is forced to discard section not because it should do so, but to make the link succeed. Other than gold, the linker for Mach-O also does not throw away unknown sections it does know about. As a result of the ld behavior, I did what hj suggested by making the section a note section, and ld behaves as expected. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from H.J. Lu --- Works for me since ld in binutils 2.26 is consistent. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #4 from David Li --- (In reply to H.J. Lu from comment #3) > (In reply to David Li from comment #2) > > (In reply to H.J. Lu from comment #1) > > > Since UNREF section is not referenced, it should be GCed. Am I missing > > > something? > > > > Note that the section does not have 'a' bit -- just like debug sections. > > Linker won't GC debug sections, right? > > ld only treats known debug sections as debug sections. Are you looking > for a way to prevent unreferenced section from GC? yes. > > > Also there is inconsistent behavior here -- when g0 is not referenced by > > UNREF, UNREF will be kept by the linker. > > g0 is removed by ld in binutils 2.26. No -- that is not the point. The point is that if UNDEF section is defined as follows, ld *will* keep UNREF (I have not tried 2.26). What makes ld think UNREF should be kept here as they are not known debug sections? .globl unref .sectionUNREF,"",@progbits .align 8 .type unref, @object .size unref, 8 unref: .long 0 .text .globl main .type main, @function -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from H.J. Lu --- Since UNREF section is not referenced, it should be GCed. Am I missing something? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #3 from H.J. Lu --- (In reply to David Li from comment #2) > (In reply to H.J. Lu from comment #1) > > Since UNREF section is not referenced, it should be GCed. Am I missing > > something? > > Note that the section does not have 'a' bit -- just like debug sections. > Linker won't GC debug sections, right? ld only treats known debug sections as debug sections. Are you looking for a way to prevent unreferenced section from GC? > Also there is inconsistent behavior here -- when g0 is not referenced by > UNREF, UNREF will be kept by the linker. g0 is removed by ld in binutils 2.26. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #5 from H.J. Lu --- (In reply to David Li from comment #4) > (In reply to H.J. Lu from comment #3) > > (In reply to David Li from comment #2) > > > (In reply to H.J. Lu from comment #1) > > > > Since UNREF section is not referenced, it should be GCed. Am I missing > > > > something? > > > > > > Note that the section does not have 'a' bit -- just like debug sections. > > > Linker won't GC debug sections, right? > > > > ld only treats known debug sections as debug sections. Are you looking > > for a way to prevent unreferenced section from GC? > > yes. > Will .globl unref .sectionUNREF,"",@note .align 8 .type unref, @object .size unref, 8 unref: .quad g0 work for you? > > > > > Also there is inconsistent behavior here -- when g0 is not referenced by > > > UNREF, UNREF will be kept by the linker. > > > > g0 is removed by ld in binutils 2.26. > > No -- that is not the point. The point is that if UNDEF section is defined > as follows, ld *will* keep UNREF (I have not tried 2.26). What makes ld > think UNREF should be kept here as they are not known debug sections? > > > > .globl unref > .sectionUNREF,"",@progbits > .align 8 > .type unref, @object > .size unref, 8 > unref: > .long 0 > > .text > .globl main > .type main, @function GCC in ld in binutils 2.26 will remove it. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #2 from David Li --- (In reply to H.J. Lu from comment #1) > Since UNREF section is not referenced, it should be GCed. Am I missing > something? Note that the section does not have 'a' bit -- just like debug sections. Linker won't GC debug sections, right? Also there is inconsistent behavior here -- when g0 is not referenced by UNREF, UNREF will be kept by the linker. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 David Li changed: What|Removed |Added CC||ccoutant at gmail dot com, ||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
https://sourceware.org/bugzilla/show_bug.cgi?id=19446 --- Comment #6 from David Li --- (In reply to H.J. Lu from comment #5) > (In reply to David Li from comment #4) > > (In reply to H.J. Lu from comment #3) > > > (In reply to David Li from comment #2) > > > > (In reply to H.J. Lu from comment #1) > > > > > Since UNREF section is not referenced, it should be GCed. Am I > > > > > missing > > > > > something? > > > > > > > > Note that the section does not have 'a' bit -- just like debug sections. > > > > Linker won't GC debug sections, right? > > > > > > ld only treats known debug sections as debug sections. Are you looking > > > for a way to prevent unreferenced section from GC? > > > > yes. > > > > Will > > .globl unref > .sectionUNREF,"",@note > .align 8 > .type unref, @object > .size unref, 8 > unref: > .quad g0 > > work for you? > > > > > > > > Also there is inconsistent behavior here -- when g0 is not referenced by > > > > UNREF, UNREF will be kept by the linker. > > > > > > g0 is removed by ld in binutils 2.26. > > > > No -- that is not the point. The point is that if UNDEF section is defined > > as follows, ld *will* keep UNREF (I have not tried 2.26). What makes ld > > think UNREF should be kept here as they are not known debug sections? > > > > > > > > .globl unref > > .sectionUNREF,"",@progbits > > .align 8 > > .type unref, @object > > .size unref, 8 > > unref: > > .long 0 > > > > .text > > .globl main > > .type main, @function > > GCC in ld in binutils 2.26 will remove it. making it a note section works fine for both ld and gold -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
