[Bug gas/29447] when gas/read.c calls mbstowcs with a NULL destination, it should set size to 0
https://sourceware.org/bugzilla/show_bug.cgi?id=29447 --- Comment #1 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=5858ac626e548772407c038b09b7837550b127dd commit 5858ac626e548772407c038b09b7837550b127dd Author: Nick Clifton Date: Fri Aug 5 10:29:48 2022 +0100 When gas/read.c calls mbstowcs with a NULL destination, it should set size to 0 PR 29447 * read.c (read_symbol_name): Pass 0 as the length parameter when invoking mbstowc in order to check the validity of a wide string. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29447] when gas/read.c calls mbstowcs with a NULL destination, it should set size to 0
https://sourceware.org/bugzilla/show_bug.cgi?id=29447 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Nick Clifton --- Patch approved and applied. (With an extra comment!) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29448] aarch64: "has a LOAD segment with RWX permissions"
https://sourceware.org/bugzilla/show_bug.cgi?id=29448 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Jérôme Forissier from comment #0) > tee.elf is produced with a custom linker script. Do you *want* a segment with read, write and execute permission ? It does represent a potential security vulnerability and it might be worth your time to examine the linker script and see if you can put the code and the data into separate segments. > Previously, no warning was output. Now that the linker warns by default, it > causes build errors with --fatal-warnings (obviously) which is a bit > annoying. Assuming that you want to keep things the way that they are you can use the --no-warn-rwx-segments command line option to disable the message. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
Re: [binutils] ar -xo Archive reports cannot set time: Invalid argument
Hi canpool, ar: 1.txt: cannot set time: Invalid argument I provide a patch bound tv_nsec： Thanks for providing a patch. As it happens this bug has already been reported and fixed: https://sourceware.org/bugzilla/show_bug.cgi?id=28391 Cheers Nick
[Bug ld/29448] aarch64: "has a LOAD segment with RWX permissions"
https://sourceware.org/bugzilla/show_bug.cgi?id=29448 --- Comment #2 from Jérôme Forissier --- (In reply to Nick Clifton from comment #1) > (In reply to Jérôme Forissier from comment #0) > > > tee.elf is produced with a custom linker script. > > Do you *want* a segment with read, write and execute permission ? Currently it doesn't matter because the ELF segment information is not used to define MMU permissions. It is a special situation, the ELF is an OS kernel, it is further processed to extract all LOAD segments and produce a raw binary. The runtime MMU mappings are defined based on delimiters (symbols) in the binary. > It does > represent a potential security vulnerability and it might be worth your time > to examine the linker script and see if you can put the code and the data > into separate segments. Yes I understand that, what I am questioning is why ld doesn't emit several LOAD segments it on its own (like Clang does for instance, with the same linker script) since I give it no constraint whatsoever. The linker script has no PHDRS instructing to merge .text .rodata .data, yet they all end up in the same segment. > > Previously, no warning was output. Now that the linker warns by default, it > > causes build errors with --fatal-warnings (obviously) which is a bit > > annoying. > > Assuming that you want to keep things the way that they are you can use the > --no-warn-rwx-segments command line option to disable the message. Yep that's a reasonable thing to do in my case, but still, I think the behavior is a bit weird. Again, ld deciding to create that RWX segment and later complaining about its own decision ;-) Thanks. -- Jerome -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29448] aarch64: "has a LOAD segment with RWX permissions"
https://sourceware.org/bugzilla/show_bug.cgi?id=29448 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #3 from Nick Clifton --- (In reply to Jérôme Forissier from comment #2) > Yep that's a reasonable thing to do in my case, but still, I think the > behavior is a bit weird. Again, ld deciding to create that RWX segment and > later complaining about its own decision ;-) To be fair, the linker isn't deciding to create the RWX segment - it is being told to do so by the linker script. Or rather the script is not giving the linker enough leeway to create separate code and data segments. But either way, the thought with the warning message is that it is better that the developer know (and ignore) about the situation, rather than live in ignorance. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29448] aarch64: "has a LOAD segment with RWX permissions"
https://sourceware.org/bugzilla/show_bug.cgi?id=29448 --- Comment #4 from Jérôme Forissier --- (In reply to Nick Clifton from comment #3) > (In reply to Jérôme Forissier from comment #2) > > > Yep that's a reasonable thing to do in my case, but still, I think the > > behavior is a bit weird. Again, ld deciding to create that RWX segment and > > later complaining about its own decision ;-) > > To be fair, the linker isn't deciding to create the RWX segment - it is > being > told to do so by the linker script. Or rather the script is not giving the > linker enough leeway to create separate code and data segments. But then how is it that the LLVM linker (ld.lld) has no problem with that? Same, linker script, and even same object files... (it generates 4 LOAD segments instead of just 2). > But either way, the thought with the warning message is that it is better > that the developer know (and ignore) about the situation, rather than live > in ignorance. Agreed on that point. -- Jerome -- You are receiving this mail because: You are on the CC list for the bug.
