[Bug ld/27567] New: Linking PE files adds alignment section flags to executables
https://sourceware.org/bugzilla/show_bug.cgi?id=27567 Bug ID: 27567 Summary: Linking PE files adds alignment section flags to executables Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: qsniyg at protonmail dot com Target Milestone: --- Created attachment 13303 --> https://sourceware.org/bugzilla/attachment.cgi?id=13303&action=edit patch to avoid section alignment flags for executables Under wine, there is currently a problem where certain DRM systems will fail if the wrong section characteristics on DLLs are detected. Currently, ld will always add IMAGE_SCN_ALIGN_* characteristics for sections, which does not match MSVC's output, therefore tripping the DRM. According to https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#section-flags, IMAGE_SCN_ALIGN_* is only valid for object files (as opposed to image/executable files). I have attached a patch that fixes this issue on my end by only applying section alignment flags to object files (!(flags & EXEC_P)). Thanks to Paul Gofman for providing the DRM research. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27567] Linking PE files adds alignment section flags to executables
https://sourceware.org/bugzilla/show_bug.cgi?id=27567 qsniyg at protonmail dot com changed: What|Removed |Added CC||qsniyg at protonmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27566] [RISC-V] relocation truncated to fit: R_RISCV_GPREL_I against aymbol
https://sourceware.org/bugzilla/show_bug.cgi?id=27566 --- Comment #2 from Nelson Chu --- Therefore, when we are doing the LUI and PCREL relaxations (GP to symbol or c.lui to symbol, must cross the DATA_SEGMENT), * If "-z relro" isn't set, then we need to reserve at most "MAXPAGESIZE" for the padding of DATA_SEGMENT_ALIGN. * If "-z relro" is set, then we need to reserve at most "MAXPAGESIZE + COMMONPAGESIZE" for the padding of DATA_SEGMENT_ALIGN and DATA_SEGMENT_RELRO_END. I only see the related checks when we are doing the LUI to C.LUI relaxation. If we want to ensure safety, then we need to do the above checks both for the LUI and PCREL relaxations, when the range crosses the DATA_SEGMENT. But consider the code size improvement, we might also need to consider the "MAXPAGESIZE" for noreloc (or "MAXPAGESIZE + COMMONPAGESIZE" for relro) when relaxing LUI/PCREL RO symbol to GPREL, that will cause the current code size worst. I'm not sure if the safest approach is needed at the moment, because the embedded target (norelro) is currently not reporting any related errors. Therefore, I would suggest that - for the "-z relro", consider the "MAXPAGESIZE + COMMONPAGESIZE" size when doing the LUI and PCREL relaxations, and the target symbol is placed in the RO-data section. And maybe we could also change the size of "2*MAXPAGESIZE" to "MAXPAGESIZE + COMMONPAGESIZE" for the C.LUI relaxation check. Though Lifang's patch, which disable the LUI relaxation when relro (only for linux toolchain), should works, but I prefer to use a unified method (consider the PAGESIZE) to check all LUI, C.LUI and PCREL relaxations. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27566] [RISC-V] relocation truncated to fit: R_RISCV_GPREL_I against aymbol
https://sourceware.org/bugzilla/show_bug.cgi?id=27566 Nelson Chu changed: What|Removed |Added CC||nelsonc1225 at sourceware dot org --- Comment #1 from Nelson Chu --- Hi Lifang, thanks for reporting this. I'm really curious how this happened, so I spend some times to research how DATA_SEGMENT_ALIGN and DATA_SEGMENT_RELRO_END work in the current GNU linker. Consider the binutils doc, * DATA_SEGMENT_ALIGN(maxpagesize, commonpagesize) = [maxpagesize == commonpagesize] (ALIGN(maxpagesize) + (. & (maxpagesize - 1))) [maxpagesize != commonpagesize] (ALIGN(maxpagesize) + ((. + commonpagesize - 1) & (maxpagesize - commonpagesize))) * DATA_SEGMENT_RELRO_END(offset, exp) When ‘-z relro’ option is not present, DATA_SEGMENT_RELRO_END does nothing, otherwise DATA_SEGMENT_ALIGN is padded so that exp + offset is aligned to the commonpagesize argument given to DATA_SEGMENT_ALIGN. I only consider the default linker script here. Besides, I do some minor changes to your original example, to see how the DATA_*_ALIGN work. nelson@LAPTOP-QFSGI1F2:~/test/pr27566$ cat tmp.s .option nopic .section.rodata .align 10 .globl hello_rodata hello_rodata: .zero 0x10 .section .init_array .globl padding_init_array padding_init_array: .zero 0xfc .text .align 1 .globl main main: lui a5,%hi(hello_rodata) addia5,a5,%lo(hello_rodata) nelson@LAPTOP-QFSGI1F2:~/test/pr27566$ ~/binutils-dev/build-linux64-upstream/build-install/bin/riscv64-unknown-linux-gnu-as tmp.s -o tmp.o Therefore, consider four cases as follows, 1. norelro, maxpagesize=0x1000, commonpagesize=0x1000 nelson@LAPTOP-QFSGI1F2:~/test/pr27566$ ~/binutils-dev/build-linux64-upstream/build-install/bin/riscv64-unknown-linux-gnu-ld -z norelro -z max-page-size=0x1000 -z common-page-size=0x1000 tmp.o -M > map1 nelson@LAPTOP-QFSGI1F2:~/test/pr27566$ cat map1 ... .rodata 0x00010400 0x10 *(.rodata .rodata.* .gnu.linkonce.r.*) .rodata0x00010400 0x10 tmp.o 0x00010400hello_rodata ... 0x00011410. = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE)) ... .init_array 0x00011410 0xfc ... 0x0001150c. = DATA_SEGMENT_RELRO_END (., 0x0) .data 0x0001150c0x0 ... DATA_SEGMENT_ALIGN should be (ALIGN(0x1000) + (0x10410 & (0x1000 - 1))) = 0x11000 + (0x10410 & 0xfff) = 0x11410 And DATA_SEGMENT_RELRO_END = 0x11410 + 0xfc = 0x1150c. So we need to reserve at most "MAXPAGESIZE" size. 2. relro, maxpagesize=0x1000, commonpagesize=0x1000 nelson@LAPTOP-QFSGI1F2:~/test/pr27566$ ~/binutils-dev/build-linux64-upstream/build-install/bin/riscv64-unknown-linux-gnu-ld -z relro -z max-page-size=0x1000 -z common-page-size=0x1000 tmp.o -M > map2 nelson@LAPTOP-QFSGI1F2:~/test/pr27566$ cat map2 ... .rodata 0x00010400 0x10 *(.rodata .rodata.* .gnu.linkonce.r.*) .rodata0x00010400 0x10 tmp.o 0x00010400hello_rodata ... 0x00011f04. = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE)) ... .init_array 0x00011f04 0xfc ... 0x00012000. = DATA_SEGMENT_RELRO_END (., 0x0) ... This is same as above, but since "-z relro", DATA_SEGMENT_RELRO_END = ALIGN(0x1150c, 0x1000) = 0x12000 DATA_SEGMENT_ALIGN = 0x12000 - 0xfc = 0x11f04 So we need to reserve at most "MAXPAGESIZE + COMMONPAGESIZE" size = "2*MAXPAGESIZE". 3. norelro, maxpagesize=0x1, commonpagesize=0x2000 nelson@LAPTOP-QFSGI1F2:~/test/pr27566$ ~/binutils-dev/build-linux64-upstream/build-install/bin/riscv64-unknown-linux-gnu-ld -z norelro -z max-page-size=0x1 -z common-page-size=0x2000 tmp.o -M > map3 nelson@LAPTOP-QFSGI1F2:~/test/pr27566$ cat map3 ... .rodata 0x00010400 0x10 *(.rodata .rodata.* .gnu.linkonce.r.*) .rodata0x00010400 0x10 tmp.o 0x00010400hello_rodata ... 0x00020410. = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE)) ... .init_array 0x00020410 0xfc ... 0x0002050c. = DATA_SEGMENT_RELRO_END (., 0x0) ... DATA_SEGMENT_ALIGN = (ALIGN(0x1) + (0x10410 & (0x2000 - 1))) = 0x2 + (0x10410 & 0x1fff) = 0x20410 DATA_SEGMENT_RELRO_END = 0x20410 + 0xfc = 0x2050c. So we need to reserve at most "MAXPAGESIZE" size. 4. relro, maxpagesize=0x1, commonpagesize=0x2000 nelson@LAPTOP-QFSGI1F2:~/test/pr27566$ ~/binutils-dev/build-linux64-upstream/build-install/bin/riscv64-unknown-linux-gnu-ld -z relro -z max-page-size=0x1 -z common-page-size=0x2000 t
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 Alex Coplan changed: What|Removed |Added CC||acoplan at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Alex Coplan --- Dup. *** This bug has been marked as a duplicate of bug 26395 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26395] binutils 2.28 Assertion failure in md_apply_fix at ../../gas/config/tc-aarch64.c:7766.
https://sourceware.org/bugzilla/show_bug.cgi?id=26395 Alex Coplan changed: What|Removed |Added CC||joel.sherrill at oarcorp dot com --- Comment #8 from Alex Coplan --- *** Bug 27217 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27443] FAIL: pr25355.o
https://sourceware.org/bugzilla/show_bug.cgi?id=27443 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi John, Not having a native hppa environment to hand (or a suitable cross compiler) I cannot run this test locally. Would you mind uploading the pr25335.o object file so that I can examine it ? (I am assuming that the test is failing because the symbols have a type that the pr25355.d file does not expect). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27447] readelf does not support DWARF 5 forms
https://sourceware.org/bugzilla/show_bug.cgi?id=27447 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|NEW |ASSIGNED CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Tom, Please could upload the testfile. (It is possible that this problem has already been fixed by other patches). You can dump the contents of the .debug_sup section using --dwarf-dump=links. (This was a recent addition to readelf...) Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26395] binutils 2.28 Assertion failure in md_apply_fix at ../../gas/config/tc-aarch64.c:7766.
https://sourceware.org/bugzilla/show_bug.cgi?id=26395
--- Comment #9 from Joel Sherrill ---
(In reply to Alex Coplan from comment #8)
> *** Bug 27217 has been marked as a duplicate of this bug. ***
It may be the same assert but I don't think it is the same trigger. The C code
in that ticket compiled successfully on every architecture:
extern char bar[];
char * foo(void)
{
return bar;
}
__asm__ (".set bar, 0");
And there was output assembly showing the breakage.
Any fix needs to be vetted against both test case code snippets.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/27487] nm: Add --just-symbol-name
https://sourceware.org/bugzilla/show_bug.cgi?id=27487 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Created attachment 13305 --> https://sourceware.org/bugzilla/attachment.cgi?id=13305&action=edit Proposed patch -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27487] nm: Add --just-symbol-name
https://sourceware.org/bugzilla/show_bug.cgi?id=27487 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nickc at redhat dot com Ever confirmed|0 |1 Last reconfirmed||2021-03-12 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Nick Clifton --- Hi Fangrui, To me this option sounds like a new output format. So please take a look at the attached patch which adds --format=just-symbols (or -j for short). Does this meet your needs ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27443] FAIL: pr25355.o
https://sourceware.org/bugzilla/show_bug.cgi?id=27443 --- Comment #2 from dave.anglin at bell dot net --- Hi Nick, Attached. Regards, Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27443] FAIL: pr25355.o
https://sourceware.org/bugzilla/show_bug.cgi?id=27443 --- Comment #3 from John David Anglin --- dave@mx3210:~/gnu/binutils/objdir/ld$ /home/dave/gnu/binutils/objdir/ld/../binutils/nm-new --plugin /home/dave/opt/test/libexec/gcc/hppa-linux-gnu/10.0.0/liblto_plugin.so tmpdir/pr25355.o > dump.out dave@mx3210:~/gnu/binutils/objdir/ld$ cat dump.out T nm_test_var T nm_test_var2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27226] ld.bfd contains huge .rodata section
https://sourceware.org/bugzilla/show_bug.cgi?id=27226 Mark Wielaard changed: What|Removed |Added CC|mjw at fedoraproject dot org | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=27215 Mark Wielaard changed: What|Removed |Added CC|mjw at fedoraproject dot org |mark at klomp dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27487] nm: Add --just-symbol-name
https://sourceware.org/bugzilla/show_bug.cgi?id=27487 --- Comment #3 from Fangrui Song --- Hi Nick, thanks for the patch! --format=just-symbols and -j look good to me. I wonder whether it is necessary to reserve -J. -J can probably be used for other purposes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27443] FAIL: pr25355.o
https://sourceware.org/bugzilla/show_bug.cgi?id=27443 --- Comment #4 from Alan Modra --- I see the same incorrect 'T' for these variables using a gcc-8.8.1 cross-compiler. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27443] FAIL: pr25355.o
https://sourceware.org/bugzilla/show_bug.cgi?id=27443 --- Comment #5 from Alan Modra --- OK, tracing this through a little, in bfd_plugin_canonicalize_symtab I see current_plugin->has_symbol_type is zero for me. This looks to be a case of my hppa-linux-gcc lto plugin using the old LDPT_ADD_SYMBOLS rather than LDPT_ADD_SYMBOLS_V2. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27443] FAIL: pr25355.o
https://sourceware.org/bugzilla/show_bug.cgi?id=27443 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Alan Modra --- And a freshly built mainline gcc (commit 3972574f11e5) gives: ~/build/cross/hppa-linux/gcc$ ~/build/gas/hppa-linux/binutils/nm-new --plugin lto-plugin/.libs/liblto_plugin.so pr25355.o B nm_test_var D nm_test_var2 And the same for a freshly built gcc-10 branch compiler (commit a07015ad4dc1), and for a freshly built gcc 10.1.0. -- You are receiving this mail because: You are on the CC list for the bug.
