[Bug ld/11539] ld --gc-sections should work for PE-COFF on MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=11539 Ard Biesheuvel changed: What|Removed |Added CC||ard.biesheuvel at linaro dot org --- Comment #18 from Ard Biesheuvel --- I have given this a spin with building the OVMF firmware (EDK2/Tianocore) http://www.tianocore.org/edk2/ In my case, I need to pass -fno-asynchrounous-unwind-tables to actually get some noticeable improvement, since the unwind info seems to hold some live references to code that is otherwise unused. But with that added, it works beautifully. (using GCC 4.9.3 + binutils-gdb 7.10 branch) -- 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 gold/18845] Using emit-relocs and icf ends in assert fail.
https://sourceware.org/bugzilla/show_bug.cgi?id=18845 --- Comment #2 from Johan Karlsson --- Right now there is a check for the -r/--gc-section/--icf combination in queue_initial_tasks(), however I think I saw a PR about it generating lots of error afterwards. Can't find it though. I don't think the patch I attached would end in an assert failing when using -r in combination with --gc-section or --icf. I'm using it to relocate a program when loading it on an embedded system. Why not an relocatable ELF is used would be due to legacy, however it works quite well to do it this way. The only drawback would be that most of the relocation entries are unnecessary. -- 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 gold/18837] gold does not handle linker-scripts with inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=18837
--- Comment #4 from Cary Coutant ---
> I see. So I'm trying (same input):
>
> SECTIONS {
> .debug_info 0 : { *(.gnu.lto_.debug_info*) }
> .debug_abbrev 0 : { *(.gnu.lto_.debug_abbrev*) }
> .debug_str 0 : { *(.gnu.lto_.debug_str*) }
> /DISCARD/ : { *(*) }
> }
>
>> ld.gold -o x -T script t.o -r
> Segmentation fault
Hmm. This seems to be due to the fact that gold is trying to create
relocation sections for each of the new sections, but the script is
preventing it from doing so (add --debug=script to see it complain
about sections it's prevented from creating). Then we go on and assume
that we have a valid output section for the relocations and end up
segfaulting when we try to dereference the null pointer. Two bugs: (a)
gold should not let the /DISCARD/ clause prevent it from creating
relocation sections; and (b) it should be more careful to assert that
the pointer is not null before dereferencing.
I think you can get it to work by adding additional section
specifications something like this:
SECTIONS {
.debug_info 0 : { *(.gnu.lto_.debug_info*) }
.debug_abbrev 0 : { *(.gnu.lto_.debug_abbrev*) }
.debug_str 0 : { *(.gnu.lto_.debug_str*) }
.rela.debug_info 0 : { *(.rela.debug_info) }
.rela.debug_abbrev 0 : { *(.rela.debug_abbrev) }
.rela.debug_str 0 : { *(.rela.debug_str) }
/DISCARD/ : { *(*) }
}
>> ld.gold -o x -T script t.o
> t.o: plugin needed to handle lto object
That's just a (hopefully) helpful message we print when we see the
symbol "__gnu_lto_slim". It's informational only.
> ld.gold: internal error in address, at ../../gold/output.h:72
Not sure what this is caused by. I'm not seeing it with a top-of-trunk
linker. (But I'm also trying a much simpler test case, so maybe I
haven't recreated your scenario closely enough.)
> maybe you can help me writing a linker script that works with GOLD and
> a partial link (and also suggest how to drop the 'E'xclude bit during
> that link)? golds "error" messages are not exactly helpful :/
Sorry, can't help you with the SHF_EXCLUDE flag. There's no way that I
know of today to have the linker ignore that flag. Doing this will
probably require additional support in the linker(s), which would
probably be best done via an extension to the plugin API rather than
the scripting language.
-cary
--
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 gold/18837] gold does not handle linker-scripts with inputs
https://sourceware.org/bugzilla/show_bug.cgi?id=18837
--- Comment #5 from rguenther at suse dot de ---
On Wed, 19 Aug 2015, ccoutant at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=18837
>
> --- Comment #4 from Cary Coutant ---
> > I see. So I'm trying (same input):
> >
> > SECTIONS {
> > .debug_info 0 : { *(.gnu.lto_.debug_info*) }
> > .debug_abbrev 0 : { *(.gnu.lto_.debug_abbrev*) }
> > .debug_str 0 : { *(.gnu.lto_.debug_str*) }
> > /DISCARD/ : { *(*) }
> > }
> >
> >> ld.gold -o x -T script t.o -r
> > Segmentation fault
>
> Hmm. This seems to be due to the fact that gold is trying to create
> relocation sections for each of the new sections, but the script is
> preventing it from doing so (add --debug=script to see it complain
> about sections it's prevented from creating). Then we go on and assume
> that we have a valid output section for the relocations and end up
> segfaulting when we try to dereference the null pointer. Two bugs: (a)
> gold should not let the /DISCARD/ clause prevent it from creating
> relocation sections; and (b) it should be more careful to assert that
> the pointer is not null before dereferencing.
>
> I think you can get it to work by adding additional section
> specifications something like this:
>
> SECTIONS {
> .debug_info 0 : { *(.gnu.lto_.debug_info*) }
> .debug_abbrev 0 : { *(.gnu.lto_.debug_abbrev*) }
> .debug_str 0 : { *(.gnu.lto_.debug_str*) }
> .rela.debug_info 0 : { *(.rela.debug_info) }
> .rela.debug_abbrev 0 : { *(.rela.debug_abbrev) }
> .rela.debug_str 0 : { *(.rela.debug_str) }
> /DISCARD/ : { *(*) }
> }
Ah, great - that indeed makes it work (thanks for the --debug=script
hit as well).
> >> ld.gold -o x -T script t.o
> > t.o: plugin needed to handle lto object
>
> That's just a (hopefully) helpful message we print when we see the
> symbol "__gnu_lto_slim". It's informational only.
Indeed. Confuses the GCC testsuite and is mildly annoying but
well ... GNU ld behaves the same way.
> > ld.gold: internal error in address, at ../../gold/output.h:72
>
> Not sure what this is caused by. I'm not seeing it with a top-of-trunk
> linker. (But I'm also trying a much simpler test case, so maybe I
> haven't recreated your scenario closely enough.)
Maybe it's because it creates the relocation section but then
the input for .debug_info is marked with SFH_EXCLUDE and things
fall apart then.
> > maybe you can help me writing a linker script that works with GOLD and
> > a partial link (and also suggest how to drop the 'E'xclude bit during
> > that link)? golds "error" messages are not exactly helpful :/
>
> Sorry, can't help you with the SHF_EXCLUDE flag. There's no way that I
> know of today to have the linker ignore that flag. Doing this will
> probably require additional support in the linker(s), which would
> probably be best done via an extension to the plugin API rather than
> the scripting language.
Indeed, I am not suggesting to extend the scripting language. But
if gold would accept a script like above (with INPUT(t.o) added)
as output from the linker plugin it could special-case that path
and ignore SHF_EXCLUDE. It could also ignore __gnu_lto_slim and
avoid giving the warning. And we'd save the intermediate I/O as well ...
That's kind-of extending the plugin API. You could as well extend it
in a more traditional way rather than via a script output, like
adding a way for the plugin to call back into the linker to tell it
to preserve and rename some sections from the original linker input
files. But the scripting way looks so appealing to me ;)
Richard.
--
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 gold/18847] Gold: Address of section moves backward when aligned.
https://sourceware.org/bugzilla/show_bug.cgi?id=18847
--- Comment #2 from Johan Karlsson ---
Created attachment 8534
--> https://sourceware.org/bugzilla/attachment.cgi?id=8534&action=edit
Linker script
I was able to reproduce it easily with my toolchain, but when I tried the
toolchain on my local distro (Binutils 2.24) I got an additional error about
segments overlap(ld.gold: error: load segment overlap [0x100 -> 0x148]
and [0x10b -> 0x101]
)
Reproduce like this using the attached linker script.
test.c:
main(){ return 0; }
gcc -c -o test.o test.c
ld.gold -T script.lcf test.o
ld.gold: error: address of section '.bss' moves backward from 0x101 to
0x10b
If I remove ALIGN from .data no error is seen. Using the attached patch I get
no error when using section alignment or not. The patch might not be enough
since I did not look into the root cause for the this->address_ being set.
--
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/18854] New: assertion fail efd/elf.c:1796 and 1731
https://sourceware.org/bugzilla/show_bug.cgi?id=18854 Bug ID: 18854 Summary: assertion fail efd/elf.c:1796 and 1731 Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: fab...@ritter-vogt.de Target Milestone: --- Created attachment 8535 --> https://sourceware.org/bugzilla/attachment.cgi?id=8535&action=edit Causes assertion fail Found by afl-fuzz again, two very similiar assertion failures: ../../objdump -d ./id\:80\,src\:000446\,op\:flip1\,pos\:8821 ../../objdump: BFD (GNU Binutils) 2.25.1 assertion fail elf.c:1796 and ../../objdump -d ./id\:000123\,src\:001057\,op\:flip1\,pos\:8821 ../../objdump: BFD (GNU Binutils) 2.25.1 assertion fail elf.c:1731 -- 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/18854] assertion fail efd/elf.c:1796 and 1731
https://sourceware.org/bugzilla/show_bug.cgi?id=18854 --- Comment #1 from Fabian Vogt --- Created attachment 8536 --> https://sourceware.org/bugzilla/attachment.cgi?id=8536&action=edit Causes another assertion fail -- 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
