[Bug ld/18808] aborting at bfd/elf64-x86-64.c:3791 in elf_x86_64_relocate_section
https://sourceware.org/bugzilla/show_bug.cgi?id=18808 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dd80eb2cff5c415a6623e144119010917922d1f7 commit dd80eb2cff5c415a6623e144119010917922d1f7 Author: Mikael Pettersson Date: Thu Sep 17 10:45:39 2020 +0100 Skip IFUNC relocations in debug sections ignored by ld.so. Fixes some ld test failures on sparc-linux-gnu. PR ld/18808 * elfxx-sparc.c (_bfd_sparc_elf_relocate_section): Skip IFUNC relocations in debug sections, change abort to _bfd_error_handler. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26404] ld: INSERT [AFTER|BEFORE] variant for extension purposes
https://sourceware.org/bugzilla/show_bug.cgi?id=26404
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2 from Nick Clifton ---
(In reply to Fangrui Song from comment #0)
[Sorry for not commenting on this PR earlier...]
Currently linker script fragments specified on the command
line override any conflicts with the built-in script, right ?
So how about:
Suggestion (d):
A new command line option to tell the linker that the
argument is a script fragment that extends the built-in
script. eg:
% cat extend.t
SECTIONS {
.data : { KEEP (*.foo) }
}
% ld --extension-script extend.t hello.o
In this scenario any .foo sections from the input files
will be added to the .data output section, *and* all the
normal input data sections (.data, .data1, etc) will also
be added to the output .data section.
This has the advantage that no new linker script syntax is needed
and the command line is more readable. (Compared to just placing
the script name on the command line without an option, which I
always find to be confusing).
Cheers
Nick
The linker already supports augmenting the built-in script via the
addition of script fragments on the command line, right ?
not just use that facility. Eg:
> * Suggestion (a)
>
> EXTEND SECTIONS { // another keyword can be used, e.g. OVERRIDE
> * Suggestion (b)
>
> SECTIONS {
> .foo : { KEEP(*(.foo)) }
> .bar : { KEEP(*(.bar)) }
> sym = .; // symbol assignments are disallowed
> } EXTEND;
>
> * Suggestion (c)
>
> SECTIONS {
> .foo : { KEEP(*(.foo)) }
> .bar : { KEEP(*(.bar)) }
> } REPLACE .data;
> // If the internal linker script defines .data, replace it with the
> content in
> // the braces. Otherwise, treat .foo and .bar as orphans?
>
> ---
>
> Some properties and edge cases need thoughts, e.g.
>
> * It had better not interfere with normal orphan placement.
> * When an output section is described by both the internal linker script and
> the
> external one, what should happen? For INSERT, the interaction is currently
> undocumented. It seems that the internal one is applied first, followed by
> the description from INSERT AFTER|BEFORE, e.g.
>
> SECTIONS { .data : { data_begin = .; *(.data) }} INSERT BEFORE .bss;
> // place .data.* into .data because the internal description does so.
>
> SECTIONS { .data : { data_begin = .; *(.data) *(.data1) }} INSERT BEFORE
> .bss;
> // place .data1 into .data
>
> ---
>
> For the two feature requests, I think they don't need to define semantics
> when
> there is a collision. The important thing is to have a syntax (not getting in
> the way in the future). The collision cases can be considered "undefined
> behaviors" for now.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26404] ld: INSERT [AFTER|BEFORE] variant for extension purposes
https://sourceware.org/bugzilla/show_bug.cgi?id=26404 --- Comment #3 from Peter Smith --- As I understand it [*] just adding the script on the command line but without the -T or --script will cause the linker to merge without the need for INSERT etc. I agree that this is not intuitive outside the use case of GROUP for files, so I think adding a command line option is useful. It would be good to concentrate on the semantics. I don't have a proposal right now, although I tend towards making the scope of the first implementation as narrow as possible. It could be expanded later on. For example just do a simple 1:1 replacement of an existing section name. If there is no-match then it can be added via the normal orphan placement rules. [*] I had a recent experience when a colleagues binary wasn't running and it was caused by forgetting -T so a full linker script got merged with the internal linker script, which unfortunately clashed enough to break the program but not report errors. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26626] Provide a hook to customize missing library error handling
https://sourceware.org/bugzilla/show_bug.cgi?id=26626 --- Comment #3 from sguelton at redhat dot com --- I Like the idea. I'll update the LLVM review to reflect that. For starters, lets focus on `normalizing' missing-library. I agree with missing-symbol foo -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26404] ld: INSERT [AFTER|BEFORE] variant for extension purposes
https://sourceware.org/bugzilla/show_bug.cgi?id=26404 --- Comment #4 from Nick Clifton --- (In reply to Peter Smith from comment #3) > As I understand it [*] just adding the script on the command line but > without the -T or --script will cause the linker to merge without the need > for INSERT etc. You are right. (I had thought that the fragment would override the built-in script where there are conflicts, but it appears that it augments it instead). So maybe what we need are *two* new command line options, just to make things clear: --augment-script= and --overwrite-script=. Hmm, maybe this is going too far. We already have -t/--script, so how about we just add --script-action=[replace|merge|overwrite|new] ? So --script-action=replace would mean that --script replaces the built-in script, as it does at the moment. --script-action=merge would mean that --script would behave like script fragments do at the moment, and augment the built-in script. --script-action=overwrite would mean the same, except that where there are multiple definitions of the same section, the definition in the script replaces the definition in the built-in. --script-action=new means that only new definitions can be added and an error is generated if there are any conflicts. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26556] relax_segment calculates incorrect target frag when OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=26556 --- Comment #4 from Nick Clifton --- Hi Tucker, Well this patch breaks some of the gas tests for targets currently use OCTETS_PER_BYTE > 1. (For example try tic54x-coff and look at the gas/org-3 test). In fact I do not see any ELF targets that use OCTETS_PER_BYTE > 1, so I am wondering where this issue is coming from. Do you have a new target that is using this feature, or a COFF/PE based target that is experiencing problems ? Anyway, my current feeling is that write.c:relax_segment() is probably not the right place to fix this problem. My gut feeling is that the fr_offset field in the frag that is being used for the common definitions needs to be octet adjusted at some earlier point. Precisely which point I do not know. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26404] ld: INSERT [AFTER|BEFORE] variant for extension purposes
https://sourceware.org/bugzilla/show_bug.cgi?id=26404 --- Comment #5 from Fangrui Song --- Nick and Peter, thanks for looking into the feature request :) (In reply to Nick Clifton from comment #4) > (In reply to Peter Smith from comment #3) > > As I understand it [*] just adding the script on the command line but > > without the -T or --script will cause the linker to merge without the need > > for INSERT etc. > > You are right. (I had thought that the fragment would override the > built-in script where there are conflicts, but it appears that it > augments it instead). > > So maybe what we need are *two* new command line options, just to make > things clear: --augment-script= and --overwrite-script=. Looks fine with me (a bit undecided on which one is better when expressing the augment/overwrite intent, with command line option or a syntax). (Currently I probably prefer a command line option more than a syntax.) > Hmm, maybe this is going too far. We already have -t/--script, so > how about we just add --script-action=[replace|merge|overwrite|new] ? > So --script-action=replace would mean that --script replaces the built-in > script, as it does at the moment. --script-action=merge would mean > that --script would behave like script fragments do at the moment, and > augment the built-in script. --script-action=overwrite would mean > the same, except that where there are multiple definitions of the same > section, the definition in the script replaces the definition in the > built-in. --script-action=new means that only new definitions can be > added and an error is generated if there are any conflicts. --script-action is position dependent and affects all the following -T/--script, right? I am wary of introducing new position dependent behaviors. In a large build system, linker options may be collected from all over the place, and having to worry about whether a lasting effect of an option can make things brittle. I have seen problems due to not closing --as-needed/-Bstatic/-Bdynamic (--start-group/--whole-archive can lead to problems as well). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26556] relax_segment calculates incorrect target frag when OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=26556 --- Comment #5 from Tucker --- Hi Nick, Thanks for the information regarding tic54x-coff and gas/org-3 test. I will re-investigate the issue with this target in mind. Regarding the target: Yes, this is a new ELF target with 16 bit bytes I've been experimenting with. The legacy tool-chain is horrific, and I've been trying to get better tools functioning on it as a side project. -Tucker -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26556] relax_segment calculates incorrect target frag when OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=26556 Tucker changed: What|Removed |Added Attachment #12810|0 |1 is obsolete|| --- Comment #6 from Tucker --- Created attachment 12848 --> https://sourceware.org/bugzilla/attachment.cgi?id=12848&action=edit Patch the offset in bss_alloc instead Nick, Traced the source of fr_offset back to bss_alloc. Applying the octet adjustment here seems to fix the issues as well as keep the org test cases happy. Just food for thought. -- You are receiving this mail because: You are on the CC list for the bug.
