[Bug ld/28824] relro security issues
https://sourceware.org/bugzilla/show_bug.cgi?id=28824 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30308] as crash (infinite recursion) on invalid source file
https://sourceware.org/bugzilla/show_bug.cgi?id=30308 Charles Blake changed: What|Removed |Added CC||charlechaud at gmail dot com --- Comment #2 from Charles Blake --- I was also able to reproduce the infinite recursion against mainline sources. -- You are receiving this mail because: You are on the CC list for the bug.
Re: ORIGIN Grammar Typo in Some Documentation
Hi Matt, Hello, just reporting that lines 492-494 of ld/ld.texi contain examples of MEMORY ORIGIN of the form: ORIGIN : offset Where the grammar is: origin_spec: ORIGIN '=' mustbe_exp Oops! Seems like hoops to raise a pull request, someone else can take the glory. Glory stolen and documentation updated. Thanks for reporting this snafu. Cheers Nick
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Pali, I am hesitant to change ld as it would mean introducing changes to the linker script syntax which might cause new bugs - and which would restrict users to using the bfd linker, instead of having a free choice. But it should be possible to provide the functionality using objcopy. In fact it might already be supported. Objcopy has a --set-section-flags option which accepts a range of arguments (alloc, load, noload, readonly, debug, code, data, rom, exclude, share, contents, merge, strings). Have you tried using this option to achieve the results you desire ? If it works, then maybe all that we need to do is to document how the arguments to the option correspond to various IMAGE_SCN_* flags. If not, then maybe we can add some more arguments that do map to the required flags. What do you think ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30144] LD --entry does not accept function name
https://sourceware.org/bugzilla/show_bug.cgi?id=30144
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1 from Nick Clifton ---
Hi Pali,
Looking into this, it is actually quite hard to predict the mangling of the
entry symbol name. But I think that there might be a simple workaround:
If you add a couple of assembler statements to define the DriverEntry symbol
then this will not be mangled by the IX86 compiler, and the duplicate
definition
will be ignored by the AMD64 assembler. ie:
asm (".set DriverEntry, .");
asm (".global DriverEntry");
__attribute__((stdcall))
long DriverEntry (void *DriverObject, void *RegistryPath) {
return 0;
}
Would this be sufficient for you ?
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/30143] All PE sections are paged
https://sourceware.org/bugzilla/show_bug.cgi?id=30143 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Pali, OK, so I am assuming that the desired behaviour is specific to the NT kernel. Ie, the default of allowing all sections to be paged is correct for most PE binaries, just not the kernel ? Given that, there needs to be some way to distinguish between building a kernel and building a normal binary and the most obvious way is to have a custom linker script for the kernel. This script can set the IMAGE_SCN_MEM_NOT_PAGED flag for all sections except one called "PAGE". Do you agree ? So what we need is a way to set PE specific section flags in linker scripts. (Which goes against what I said for PR 30145, but I am going through these PRs in reverse order and I now see that there is a genuine need to extend the linker script syntax). The linker currently supports setting a section's type via the "TYPE=xxx" syntax, but that is not quite what we need, since presumably there might be a need to set more than one flag. So I guess that we need to add a "FLAG=xxx[|xxx]+" syntax. Then, since the flags are going to be file format/architecture specific, we need to implement a callback into the linker's emulation framework in order to parse the flags, and another one to set them. Plus we need to add support for the NOT_PAGED flag to the BFD library (since it currently does not support it at all). *sigh* I was right about this being a big potential source for new bugs. It would be a lot easier to just use objcopy to set the flag after the the link has completed... Any thoughts ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30281] error: multiple definition of `pwrite@GLIBC_2.2' with LTO and symver attribute
https://sourceware.org/bugzilla/show_bug.cgi?id=30281 --- Comment #10 from Martin Liska --- Thanks H.J. for the backport. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30142] PE .rsrc section is generated as writable
https://sourceware.org/bugzilla/show_bug.cgi?id=30142 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Ever confirmed|0 |1 Last reconfirmed||2023-04-12 Status|UNCONFIRMED |ASSIGNED CC||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30142] PE .rsrc section is generated as writable
https://sourceware.org/bugzilla/show_bug.cgi?id=30142 --- Comment #1 from Nick Clifton --- Created attachment 14815 --> https://sourceware.org/bugzilla/attachment.cgi?id=14815&action=edit Proposed patch Hi Pali, Please could you try out this patch and see if it works for you ? The fault lies with the windres program, not the linker. The windres program is setting the IMAGE_SCN_MEM_WRITE flag when it creates the .rsrc section, and the linker is then preserving this flag when it runs. So the patch fixes windres so that it no longer sets the flag, and this in turn means that the linked executable will have a read-only .rsrc section. Cheers Nick -- 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 CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Created attachment 14816 --> https://sourceware.org/bugzilla/attachment.cgi?id=14816&action=edit Proposed patch Hi Pali, Please try out this patch and let me know if it works for you. I must admit that for the longest time I was blaming the lto plugin rather than the linker, but it turns out that I was wrong. The key fact is that if the user adds "-e " to the linker command line then code in ld/ldemul.c adds an unresolved reference to which in turn prevents the LTO compiler from optimizing away any definitions of . When -e is not used, this undefined reference (to the default startup symbol _mainCRTStartup) was not being created and so the LTO compiler was dropping the code... Cheers Nick -- 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 Assignee|unassigned at sourceware dot org |nickc at redhat dot com -- 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 Last reconfirmed||2023-04-12 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.
Issue 57789 in oss-fuzz: binutils:fuzz_objdump_safe: Null-dereference READ in bfd_coff_get_syment
Updates: Labels: -restrict-view-commit Comment #3 on issue 57789 by sheriffbot: binutils:fuzz_objdump_safe: Null-dereference READ in bfd_coff_get_syment https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57789#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 57879 in oss-fuzz: binutils:fuzz_nm: Index-out-of-bounds in insert_arange_in_trie
Updates: Labels: -restrict-view-commit Comment #3 on issue 57879 by sheriffbot: binutils:fuzz_nm: Index-out-of-bounds in insert_arange_in_trie https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57879#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug ld/30144] LD --entry does not accept function name
https://sourceware.org/bugzilla/show_bug.cgi?id=30144
--- Comment #2 from Pali Rohár ---
As a workaround I have already come up with this:
__attribute__((stdcall)) long DriverEntry(void *DriverObject, void
*RegistryPath) asm("DriverEntry");
__attribute__((stdcall)) long DriverEntry(void *DriverObject, void
*RegistryPath) {
return 0;
}
And then you can use -Wl,--entry=DriverEntry for both AMD64 and IX86 archs.
Via asm keyword in function declaration you can specify symbol name of the
function itself.
And because entry point symbol is basically used only by linker for filling
base address field in PE binary, it can be anything.
But this is still a workaround because it is not practical to add #ifdef for
GNU tools into source code. Specially when MS tools do not need any special
arch dependent command line switch or #ifdef. Switch /ENTRY:DriverEntry works
for both AMD64 and IX86.
I thought that it could be relatively easy for PE IX86 version of LD to search
for symbol _XYZ@number when symbol XYZ specified in --entry does not exist.
Specially because there is some logic related to this (--kill-at). But I have
not looked at source code, so this was just my speculation...
Another option would be to implement switch to instruct gcc (or ld) to "compile
NT kernel driver" (I created issue for it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108852) and part of it for IX86
platform could be automatic passing of --entry=_DriverEntry@8.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 --- Comment #2 from Pali Rohár --- In past I have tried to use objcopy --set-section-flags but it did not work, I did not get expected result and I do not remember exact details. As you mentioned this option, I will try it again with new binutils version and let you know what are the results, including test cases (for reproducibility in future). For sure objcopy should support changing PE section characteristics. As objcopy is commonly used for changing / extracting sections of object files or executables. Ability to specify it directly in linker would be useful, but well, for sure you know better if it is hard to implement it and what can be impact on (new?) bugs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30143] All PE sections are paged
https://sourceware.org/bugzilla/show_bug.cgi?id=30143 --- Comment #2 from Pali Rohár --- Hello! I'm replying below as inline comments. (In reply to Nick Clifton from comment #1) > Hi Pali, > > OK, so I am assuming that the desired behaviour is specific to the NT > kernel. > Ie, the default of allowing all sections to be paged is correct for most PE > binaries, just not the kernel ? Yes, this issue is about NT kernel drivers. For NT user PE executables is current behavior correct. > Given that, there needs to be some way to distinguish between building a > kernel > and building a normal binary and the most obvious way is to have a custom > linker script for the kernel. This script can set the > IMAGE_SCN_MEM_NOT_PAGED > flag for all sections except one called "PAGE". Do you agree ? For sure distinguish between NT kernel driver executables and PE user executables is needed. And what kind of solution for this is used (custom linker script, compile switch, ...) I will let to you / binutils developers. I think that this depends on architecture of the whole project and I do not think that I see what is the best choice here. Linker script is being specified by the command line option, so if this new linker script would be as part of the "standard" PE binutils installation then for user/developer perspective it is same as the "command line switch" way. > So what we need is a way to set PE specific section flags in linker > scripts. > (Which goes against what I said for PR 30145, but I am going through these > PRs in reverse order and I now see that there is a genuine need to extend > the linker script syntax). Ok. I know what whole picture is not simple, so I would expect that the final solution can be changed in time / during development. > The linker currently supports setting a section's type via the "TYPE=xxx" > syntax, but that is not quite what we need, since presumably there might > be a need to set more than one flag. So I guess that we need to add a > "FLAG=xxx[|xxx]+" syntax. Then, since the flags are going to be file > format/architecture specific, we need to implement a callback into the > linker's emulation framework in order to parse the flags, and another one > to set them. Plus we need to add support for the NOT_PAGED flag to the > BFD library (since it currently does not support it at all). *sigh* I > was right about this being a big potential source for new bugs. > > It would be a lot easier to just use objcopy to set the flag after the > the link has completed... In past I have already tried to use objcopy for setting those flags, but whatever I did was not able. Not sure if there is missing documentation for it, or it is really not supported (as I created an issue for it). But my current usage is to compile code, link object files to binary and then post-process this binary to fix these flags via my custom tool. Replacing my custom tool by standard objcopy tool is a step forward. >From "user" perspective, it would be better to allow specifying these flags directly into linker. > Any thoughts ? > > Cheers > Nick Another idea: What about extending GNU AS to allow setting these flags into COFF object file? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30140] LD does not link PE executable with symbols from DEF file
https://sourceware.org/bugzilla/show_bug.cgi?id=30140 --- Comment #3 from Pali Rohár --- Thank you for information. I see that it is quite misleading because DEF file in some case is used for "dllimport" functionality and in some other cases is used for "dllexport" functionality. And this can be even more confusing when building DLL library because it can do both things: import external symbols and export its own symbols. Eric Botcazou: It is quite pity that this is not supported, because more or less DEF file is text description of the binary import library, which is used for indirect linking. Direct linking with DLL file is nice feature but unusable for Windows system libraries (as they are not re-distributable and hence not part of any toolchain). I see benefit of usage of text files compared to binary. But I understand that you do not want to support or implement another option for linking. In the example from the issue description, I invoked gcc for building PE executable (and not DLL library). And if DEF file passed to gcc specify "dllexport" stuff, meaning which functions will be exported from _currently building DLL library_ as specified in LIBRARY keyword in DEF file, then I have feeling that this combination of command line options passed to gcc does not make sense, and gcc or ld should throw compile or link error. For example: Error: Compiling executable (because -shared nor -dll was not passed to gcc) but passed DEF file contains LIBRARY keyword suitable when compiling DLL library. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30147] Allow to specify PE export name
https://sourceware.org/bugzilla/show_bug.cgi?id=30147 --- Comment #3 from Pali Rohár --- I have tested that it is really possible to set export name via DEF file when generating PE binary. Export name can be specified via LIBRARY or via NAME keyword. At least I would suggest to extend -soname= documentation and mention there this information how to set PE export name. -- You are receiving this mail because: You are on the CC list for the bug.
