[Bug ld/30343] LTO ignores linker reference to _pei386_runtime_relocator
https://sourceware.org/bugzilla/show_bug.cgi?id=30343 Alan Modra changed: What|Removed |Added Assignee|amodra at gmail dot com|unassigned at sourceware dot org Summary|LTO drops explicitly|LTO ignores linker |referenced symbol |reference to |_pei386_runtime_relocator |_pei386_runtime_relocator CC||amodra at gmail dot com Status|ASSIGNED|NEW --- Comment #2 from Alan Modra --- I'm removing myself as assignee for this bug. I don't really know enough about details of the PE support code to take this one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30343] LTO drops explicitly referenced symbol _pei386_runtime_relocator
https://sourceware.org/bugzilla/show_bug.cgi?id=30343 --- Comment #1 from Alan Modra --- Created attachment 14841 --> https://sourceware.org/bugzilla/attachment.cgi?id=14841=edit run pe after_open earlier This cures the _pei386_runtime_relocator problem but unfortunately results in "undefined reference to `arr'". Very likely parts of the pe after_open function need to run both before plugin_call_all_symbols_read and after the LTO plugin has recompiled code. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30343] LTO drops explicitly referenced symbol _pei386_runtime_relocator
https://sourceware.org/bugzilla/show_bug.cgi?id=30343 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-04-18 Assignee|unassigned at sourceware dot org |amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30360] [gprofng collect] Seg. Fault when application uses std::thread
https://sourceware.org/bugzilla/show_bug.cgi?id=30360 Vladimir Mezentsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Vladimir Mezentsev --- Update status as resolved/fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #2 from Pali Rohár --- If adding empty import table and something in code .text sections is feature of the linker, it is somewhere documented? What it is doing and what is putting there (as those sections are not in any user supplied input file)? And I'm interesting why it is doing, it is some requirement for some SW? Just I'm currious here. And about objcopy --remove-section workaround, this is problematic because for automatization, it is needed to know what sections has to be removed - meaning ability to ask LD what additional section it added there. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30367] Performance regression after updating to 2.40
https://sourceware.org/bugzilla/show_bug.cgi?id=30367 --- Comment #3 from Mark Street --- Just tested your proposed patch against the N64 project: root@5e98d9b5788e:/sssv# time mips-elf-ld -T sssv.ld -T undefined_syms.us.txt -T undefined_syms_auto.txt -Map build/sssv.us.map --no-check-sections -Lbuild/lib -lultra_rom -u osViGetCurrentLine -o build/sssv.us.elf real0m0.324s user0m0.283s sys 0m0.041s Much better! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #8 from Nick Clifton --- (In reply to Stas Sergeev from comment #7) Hi Stas, > In a mean time, if your patch doesn't fix that, > then will you provide another patch? I will try to provide another patch - or an updated version of the original patch. This does depend upon why the original patch fails though... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30367] Performance regression after updating to 2.40
https://sourceware.org/bugzilla/show_bug.cgi?id=30367 --- Comment #2 from Michael Matz --- No need to dig into trying with an empty ROM. It's easily reproducable with many input files each being used in a wildstatement of a linker script. It's a quadraticness problem. Proposed fix at https://sourceware.org/pipermail/binutils/2023-April/127120.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30367] Performance regression after updating to 2.40
https://sourceware.org/bugzilla/show_bug.cgi?id=30367 Michael Matz changed: What|Removed |Added Last reconfirmed||2023-04-18 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |matz at suse dot de --- Comment #1 from Michael Matz --- So the specific feature heavily used in the linker script seems to be section descriptions based on filenames. I will try to create a reproducer for this situation locally, but it would also help if I had a way to test it better in your setup. Is there any possibility you could make it so that I can build/test your github project _without_ having access to the N64 ROM? (E.g. by replacing it with an all-zeros ROM for instance? The result won't work, but I'm only interested in building anyway.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #7 from Stas Sergeev --- (In reply to Nick Clifton from comment #6) > It doesn't. :-( But you can fix the problem by rearranging the order of the > object files on the link command line: Thanks, waiting for the test results from client. In a mean time, if your patch doesn't fix that, then will you provide another patch? Or is this not a bug, or is this not the same bug that was reported here, or what is the status? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28910] GNU-ld: ARM: Issues when trying to set target output architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=28910 --- Comment #6 from Nick Clifton --- (In reply to Stas Sergeev from comment #5) > Created attachment 14836 [details] > test case > > This test-case ends with > > ld: error: source object obj2.o has EABI version 5, but target out.o has > EABI version 0 > ld: failed to merge target specific data of file obj2.o > make: *** [Makefile:4: out.o] Error 1 > > Nick, could you please check if your patch > fixes this? Seems a bit easier than to > convince people to test the patch. It doesn't. :-( But you can fix the problem by rearranging the order of the object files on the link command line: ld -r -o out.o obj2.o obj1.o This will remove the error, although you may still get a warning about obj2.o not having a .note.GNU-stack section. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30355] [DWARFv5] readelf: loc_offset XX too big
https://sourceware.org/bugzilla/show_bug.cgi?id=30355 --- Comment #3 from Nick Clifton --- (In reply to Nick Desaulniers from comment #2) > What's the best way to strip out the debug info? > > $ objcopy --only-keep-debug vmlinux vmlinux-debug > $ du -h vmlinux vmlinux-debug > 34M vmlinux > 33M vmlinux-debug > > Looks like .text was retained. Hmm. Well that is odd. The command line that you used was exactly what I would have suggested. Maybe this will work instead: objcopy --only-section=".debug.*" vmlinux vnlinux-debug -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Pali Rohár from comment #0) Hi Pali, > I'm trying to achieve same thing via binutils, but even with stripped debug > symbols and zero entry point, LD somehow always puts .idata and .text > sections with empty import table and something in code .text sections. *sigh* Yes this is a "feature" of the linker. It might be possible to hack the linker to change the behaviour, but I think that there is a simpler solution: > $ i686-w64-mingw32-windres --input-format=rc --output-format=coff > --input=test-rsrc.rc --output=test-rsrc.o > > $ i686-w64-mingw32-ld -dll --subsystem windows -e 0 -s test-rsrc.o -o > test-rsrc.dll > > $ i686-w64-mingw32-objdump -h test-rsrc.dll > > test-rsrc.dll: file format pei-i386 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 0010 10001000 10001000 0400 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 1 .idata0014 10002000 10002000 0600 2**2 > CONTENTS, ALLOC, LOAD, DATA > 2 .rsrc 00b8 10003000 10003000 0800 2**2 > CONTENTS, ALLOC, LOAD, DATA But if you add $ i686-w64-mingw32-objcopy --remove-section .text --remove-section .idata test-rsrc.dll test-rsrc-2.dll then... $ i686-w64-mingw32-objdump -h test-rsrc-2.dll test-rsrc-2.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .rsrc 00b8 10003000 10003000 0200 2**2 CONTENTS, ALLOC, LOAD, DATA I realise that this means adding another step to the process, but it also means that the workaround will work with the current tools, no need for any updates. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30367] Performance regression after updating to 2.40
https://sourceware.org/bugzilla/show_bug.cgi?id=30367 Alan Modra changed: What|Removed |Added CC||matz at suse dot de -- You are receiving this mail because: You are on the CC list for the bug.
