[Bug ld/30300] LTO drops entry point symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=30300 --- Comment #4 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=3539414584be0094b0a4fe56dfd64ea79d802edc commit 3539414584be0094b0a4fe56dfd64ea79d802edc Author: Nick Clifton Date: Thu May 4 14:24:16 2023 +0100 Stop the linker from loosing the entry point for COFF/PE code when compiling with LTO enabled. PR 30300 * emultempl/pep.em (set_entry_point): Add an undefined reference to the entry point if it has been constructed heuristically. * emultempl/pe.em (set_entry_point): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30300] LTO drops entry point symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=30300 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Nick Clifton --- (In reply to Pali Rohár from comment #3) > Do you need some more testing? No - just me needing a reminder. (I have so many balls in the air at the moment..) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30354] Debug info is lost for functions only called from functions marked with cmse_nonsecure_entry
https://sourceware.org/bugzilla/show_bug.cgi?id=30354 Nick Clifton changed: What|Removed |Added Attachment #14851|0 |1 is obsolete|| --- Comment #7 from Nick Clifton --- Created attachment 14860 --> https://sourceware.org/bugzilla/attachment.cgi?id=14860&action=edit Proposed patch Hi Torbjörn > Just looking at the patch, I'm a bit confused about the variable > "extra_marks_added". > The initial value is true, and in the function body, > it's set to true in certain > cases, but it's never set to false and thus, the if-statement at the end of > the patch > should always happen. Is this the desired behavior? Oops - snafu. Please try out this corrected version which initialises extra_marks_added to false... Cheers Nick -- 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 #11 from Nick Clifton --- Created attachment 14861 --> https://sourceware.org/bugzilla/attachment.cgi?id=14861&action=edit Example linker script Hi Pali, OK, so the problem was the linker script that I was using, which was not initialising the starting VMA address in the same way as the default linker script. After I fixed that, the script appears to work. Please give it a go and let me know if it works for you too. (I have uploaded it to this PR). Assuming that it does work, are you happy to have this as a solution to the problem ? It does mean that you will have a fix that will work with the current linker (or earlier versions), instead of having to wait for the release of a new linker. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30354] Debug info is lost for functions only called from functions marked with cmse_nonsecure_entry
https://sourceware.org/bugzilla/show_bug.cgi?id=30354 --- Comment #8 from Torbjörn SVENSSON --- (In reply to Nick Clifton from comment #7) > Created attachment 14860 [details] > Proposed patch > > Oops - snafu. Please try out this corrected version which initialises > extra_marks_added to false... I can confirm that this patch works using GDB to step into the "bar" function in the demonstrator attached to this bug report. I've also checked that the dwarf information (readelf -w) contains the "bar" symbol. With this patch, I would consider this ticket resolved. I suppose that the patch will be sent to the ML for review. Prior to sending the patch, I can just say that there is a blank line added and an indentation change. I'm not sure if those changes were intended or if it slipped though when you did the test patch for me. And finally, thanks for proposing a patch for the issue! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30421] New: Symbols in import lib are influenced by .def file
https://sourceware.org/bugzilla/show_bug.cgi?id=30421 Bug ID: 30421 Summary: Symbols in import lib are influenced by .def file Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: luca.bacci at outlook dot com Target Milestone: --- Hello! I'm experiencing an issue when building a shared library / DLL for the x86 architecture using gcc. All public functions use the __stdcall calling convention and are exported using a .def file so to have undecorated names in the resulting DLL. That is helpful for users that want to use GetProcAddress(). However gcc generates an import lib with undecorated names also in the symbols table. That causes linking errors, because the compiler can only know about decorated symbols. The error doesn't happen when building with other compilers like clang or msvc. The resulting import libraries always have decorated symbols. See also the relevant discussion at https://sourceforge.net/p/mingw-w64/mailman/message/37839853/ Thank you very much! Luca Bacci -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30421] Symbols in import lib are influenced by .def file
https://sourceware.org/bugzilla/show_bug.cgi?id=30421 --- Comment #1 from Luca Bacci --- As linked in the discussion, there's a sample repo at https://github.com/lb90/my-shared-lib Another report of the issue is at https://github.com/KhronosGroup/OpenCL-ICD-Loader/issues/191 Thanks, Luca -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30421] Symbols in import lib are influenced by .def file
https://sourceware.org/bugzilla/show_bug.cgi?id=30421 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com -- You are receiving this mail because: You are on the CC list for the bug.
