[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 mintsuki changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #19 from mintsuki --- Why are shared libraries (linked with -shared) allowed to have a non-0 load address? Is this a bug or is this intended behaviour? If it is intended behaviour, then what is said behaviour? Why would said behaviour be any different compared to a -pie with a non-0 load address? I am sorry for my insistence, it's just that I strongly feel like forcing the ELF type to ET_EXEC with non-0 load addresses is a bug; a workaround for a specific situation from 10 years ago that should've never been added... Even the documentation you added doesn't really make anything clear, as it makes assumptions about the loader that are not necessarily what the ELF specification mandates, as far as I can tell. To be more specific, I am the author and main developer of the Limine bootloader; the Limine bootloader has its own boot protocol supporting loading 64-bit ELF files. When loading relocatable ELFs, so far what I had to do was ignore the ET_EXEC file type and instead rely on the presence of the DF_1_PIE flag (which your linker emits anyways even if the ELF type is forced to ET_EXEC) to determine whether an ELF file is relocatable or not (if the type wasn't ET_DYN already). This is because ld.bfd refuses to generate PIE ELFs with a non-0 base and ET_DYN type. There are solutions like recommending people to generate shared objects instead of PIEs, but I feel like that's almost like relying on a workaround to avoid the workaround, and I do not like that. The other solution was what I thought about doing first, which is to set the load address to 0; but as I mentioned before, that breaks addr2line, objdump, and friends if looking for the raw virtual address of something... Is this workaround in ld.bfd *really* still necessary after 10 years from when it was added? Can you please strongly consider reverting this behaviour? I would be extremely grateful if that was done. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] New: src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 Bug ID: 31800 Summary: src-release.sh recursively changes permissions of everything in to 0777 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: rostiprodev at gmail dot com Target Milestone: --- After running this script permissions of all files and directories (including files of Git repo and the root directory of the project) are changed to 0777, i.e. everything is open for everybody for any read-write operation. This is not good, not secure and must never be done. The src-release.sh script does it by the following line: chmod -R og=u . || chmod og=u `find . -print` Please remove this line. The src-release.sh works properly without that line and doesn't change permissions of files or directories. In case a particular file must have special permissions you can change those permissions in the Git repository. Git always stores file permissions of all BLOB (file) and TREE (directory) object in the appropriate TREE objects that point to (have) them. For more information read: [1] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#_tree_objects [2] https://adamj.eu/tech/2023/01/31/git-add-remove-execute-permissions/ I found this issue in the "binutils-2_42-branch" Git branch but it exists in master and in some older branches as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 Rostislav Krasny changed: What|Removed |Added CC||rostiprodev at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 H.J. Lu changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=31799 Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #20 from H.J. Lu --- It turns out that static PIE with non-zero load address must have ET_EXEC: https://sourceware.org/bugzilla/show_bug.cgi?id=31799 Otherwise, there is no way for loader to tell if the dynamic section entries contain the relocated values for the load address or not. Since static PIE with non-zero load address must have ET_EXEC, PIE with non-zero load address also should have ET_EXEC. BTW, gold doesn't support static PIE and static PIE with non-zero load address generated by lld crashes with the fix glibc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #21 from mintsuki --- (In reply to H.J. Lu from comment #20) > It turns out that static PIE with non-zero load address must have ET_EXEC: > > https://sourceware.org/bugzilla/show_bug.cgi?id=31799 > > Otherwise, there is no way for loader to tell if the dynamic section entries > contain the relocated values for the load address or not. Since static PIE > with non-zero load address must have ET_EXEC, PIE with non-zero load address > also should have ET_EXEC. > > BTW, gold doesn't support static PIE and static PIE with non-zero load > address > generated by lld crashes with the fix glibc. At least in the context of making a kernel, gold does generate a static-pie, at least as printed out by the file command, and the output of readelf -a looks similar to ld.bfd's -static -pie generation, even without the -static part. I assume this is because no other dynamic libraries are linked in when using -nostdlib and not specifying any dynamic library explicitly. I do not know what the problem with glibc is, but static-pie kernels loaded by Limine with a non-0 load address (or shared objects with a non-0 load address for that matter) work perfectly fine if relocated (at or above whatever specified non-0 load address). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #22 from mintsuki --- As far as I can tell, the linked issue seems to indicate more so that this is indeed a problem rather than some glibc bug. Does glibc crash without any patch if you patch ld.bfd to create an ET_DYN instead? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #23 from H.J. Lu --- (In reply to mintsuki from comment #21) > (In reply to H.J. Lu from comment #20) > > It turns out that static PIE with non-zero load address must have ET_EXEC: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=31799 > > > > Otherwise, there is no way for loader to tell if the dynamic section entries > > contain the relocated values for the load address or not. Since static PIE > > with non-zero load address must have ET_EXEC, PIE with non-zero load address > > also should have ET_EXEC. > > > > BTW, gold doesn't support static PIE and static PIE with non-zero load > > address > > generated by lld crashes with the fix glibc. > > At least in the context of making a kernel, gold does generate a static-pie, > at least as printed out by the file command, and the output of readelf -a > looks similar to ld.bfd's -static -pie generation, even without the -static > part. [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c -fuse-ld=lld [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c -fuse-ld=gold /usr/local/bin/ld.gold: --no-dynamic-linker: unknown option /usr/local/bin/ld.gold: use the --help option for usage information collect2: error: ld returned 1 exit status [hjl@gnu-cfl-3 tmp]$ > I assume this is because no other dynamic libraries are linked in when using > -nostdlib and not specifying any dynamic library explicitly. > > I do not know what the problem with glibc is, but static-pie kernels loaded > by Limine with a non-0 load address (or shared objects with a non-0 load > address for that matter) work perfectly fine if relocated (at or above > whatever specified non-0 load address). Does your kernel have any dynamic tags which need relocation? [hjl@gnu-cfl-3 tmp]$ readelf -d /bin/ld Dynamic section at offset 0x11f4a8 contains 35 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libbfd-2.42.50.0.1.20240523.so] 0x0001 (NEEDED) Shared library: [libctf.so.0] 0x0001 (NEEDED) Shared library: [libjansson.so.4] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x000c (INIT) 0x6000 0x000d (FINI) 0x4e594 0x0019 (INIT_ARRAY) 0x1197f0 0x001b (INIT_ARRAYSZ) 8 (bytes) 0x001a (FINI_ARRAY) 0x1197f8 0x001c (FINI_ARRAYSZ) 8 (bytes) 0x6ef5 (GNU_HASH) 0x460 0x0005 (STRTAB) 0x2148 0x0006 (SYMTAB) 0x540 0x000a (STRSZ) 4860 (bytes) 0x000b (SYMENT) 24 (bytes) 0x7000 (DT_X86_64_PLT) 0x7140 0x7001 (DT_X86_64_PLTSZ)0x10c0 0x7003 (DT_X86_64_PLTENT) 0x10 0x0015 (DEBUG) 0x0 0x0003 (PLTGOT) 0x120728 0x0002 (PLTRELSZ) 6432 (bytes) 0x0014 (PLTREL) RELA 0x0017 (JMPREL) 0x39c8 0x0007 (RELA) 0x37a0 0x0008 (RELASZ) 552 (bytes) 0x0009 (RELAENT)24 (bytes) 0x001e (FLAGS) BIND_NOW 0x6ffb (FLAGS_1)Flags: NOW PIE 0x6ffe (VERNEED)0x36a0 0x6fff (VERNEEDNUM) 2 0x6ff0 (VERSYM) 0x3444 0x0024 (RELR) 0x52e8 0x0023 (RELRSZ) 536 (bytes) 0x0025 (RELRENT)8 (bytes) 0x (NULL) 0x0 [hjl@gnu-cfl-3 tmp]$ These dynamic tags with addresses must be relocated before accessing the memory. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #24 from H.J. Lu --- (In reply to mintsuki from comment #22) > As far as I can tell, the linked issue seems to indicate more so that this > is indeed a problem rather than some glibc bug. > > Does glibc crash without any patch if you patch ld.bfd to create an ET_DYN > instead? My ld ET_EXEC change predates static PIE. lld generates ET_DYN and there is no way for static PIE with non-zero load address to work if marked ET_DYN. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #25 from mintsuki --- (In reply to H.J. Lu from comment #23) > (In reply to mintsuki from comment #21) > > (In reply to H.J. Lu from comment #20) > > > It turns out that static PIE with non-zero load address must have ET_EXEC: > > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=31799 > > > > > > Otherwise, there is no way for loader to tell if the dynamic section > > > entries > > > contain the relocated values for the load address or not. Since static > > > PIE > > > with non-zero load address must have ET_EXEC, PIE with non-zero load > > > address > > > also should have ET_EXEC. > > > > > > BTW, gold doesn't support static PIE and static PIE with non-zero load > > > address > > > generated by lld crashes with the fix glibc. > > > > At least in the context of making a kernel, gold does generate a static-pie, > > at least as printed out by the file command, and the output of readelf -a > > looks similar to ld.bfd's -static -pie generation, even without the -static > > part. > > [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c > [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c -fuse-ld=lld > [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c -fuse-ld=gold > /usr/local/bin/ld.gold: --no-dynamic-linker: unknown option > /usr/local/bin/ld.gold: use the --help option for usage information > collect2: error: ld returned 1 exit status > [hjl@gnu-cfl-3 tmp]$ This is not an issue if you call ld.gold manually as done by the kernel in question (see above test case). I know that "you should not invoke the linker outside the driver" and I do agree, but I do make an exception for linking bare metal, freestanding stuff, as I like to have more control over the linking process. With that, I just didn't pass --no-dynamic-linker (as it is not supported by gold, and the linker script makes it a non issue), and I didn't pass -static, as frankly it seems to do nothing anyways when linking a -nostdlib -pie kernel, and isn't supported by gold in combination with -pie. Please once again see the test case above. > > > I assume this is because no other dynamic libraries are linked in when using > > -nostdlib and not specifying any dynamic library explicitly. > > > > I do not know what the problem with glibc is, but static-pie kernels loaded > > by Limine with a non-0 load address (or shared objects with a non-0 load > > address for that matter) work perfectly fine if relocated (at or above > > whatever specified non-0 load address). > > Does your kernel have any dynamic tags which need relocation? > > [hjl@gnu-cfl-3 tmp]$ readelf -d /bin/ld > > Dynamic section at offset 0x11f4a8 contains 35 entries: > TagType Name/Value > 0x0001 (NEEDED) Shared library: > [libbfd-2.42.50.0.1.20240523.so] > 0x0001 (NEEDED) Shared library: [libctf.so.0] > 0x0001 (NEEDED) Shared library: [libjansson.so.4] > 0x0001 (NEEDED) Shared library: [libc.so.6] > 0x000c (INIT) 0x6000 > 0x000d (FINI) 0x4e594 > 0x0019 (INIT_ARRAY) 0x1197f0 > 0x001b (INIT_ARRAYSZ) 8 (bytes) > 0x001a (FINI_ARRAY) 0x1197f8 > 0x001c (FINI_ARRAYSZ) 8 (bytes) > 0x6ef5 (GNU_HASH) 0x460 > 0x0005 (STRTAB) 0x2148 > 0x0006 (SYMTAB) 0x540 > 0x000a (STRSZ) 4860 (bytes) > 0x000b (SYMENT) 24 (bytes) > 0x7000 (DT_X86_64_PLT) 0x7140 > 0x7001 (DT_X86_64_PLTSZ)0x10c0 > 0x7003 (DT_X86_64_PLTENT) 0x10 > 0x0015 (DEBUG) 0x0 > 0x0003 (PLTGOT) 0x120728 > 0x0002 (PLTRELSZ) 6432 (bytes) > 0x0014 (PLTREL) RELA > 0x0017 (JMPREL) 0x39c8 > 0x0007 (RELA) 0x37a0 > 0x0008 (RELASZ) 552 (bytes) > 0x0009 (RELAENT)24 (bytes) > 0x001e (FLAGS) BIND_NOW > 0x6ffb (FLAGS_1)Flags: NOW PIE > 0x6ffe (VERNEED)0x36a0 > 0x6fff (VERNEEDNUM) 2 > 0x6ff0 (VERSYM) 0x3444 > 0x0024 (RELR) 0x52e8 > 0x0023 (RELRSZ) 536 (bytes) > 0x0025 (RELRENT)8 (bytes) > 0x (NULL) 0x0 > [hjl@gnu-cfl-3 tmp]$ > > These dynamic tags with addresses must be relocated before accessing the > memory. The test case above is too small to have any necessary relocation, but I have another kernel using the same build system that has plenty of R_X86_64_RELATIVE relocations and it works fine after Limine relocates it. -- You are receivin
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #26 from mintsuki --- (In reply to H.J. Lu from comment #24) > (In reply to mintsuki from comment #22) > > As far as I can tell, the linked issue seems to indicate more so that this > > is indeed a problem rather than some glibc bug. > > > > Does glibc crash without any patch if you patch ld.bfd to create an ET_DYN > > instead? > > My ld ET_EXEC change predates static PIE. lld generates ET_DYN and there is > no way for static PIE with non-zero load address to work if marked ET_DYN. Well, evidently it works fine enough for Limine to load these properly as made by ld.bfd, lld, or gold... Honestly to me this seems more of a glibc bug than anything, unless I am missing something. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #27 from mintsuki --- This is the aforementioned other kernel's readelf -d output: Dynamic section at offset 0x46b70 contains 13 entries: TagType Name/Value 0x0004 (HASH) 0x8003c140 0x6ef5 (GNU_HASH) 0x8003c150 0x0005 (STRTAB) 0x8003c138 0x0006 (SYMTAB) 0x8003c120 0x000a (STRSZ) 1 (bytes) 0x000b (SYMENT) 24 (bytes) 0x0015 (DEBUG) 0x0 0x0007 (RELA) 0x8003c170 0x0008 (RELASZ) 27264 (bytes) 0x0009 (RELAENT)24 (bytes) 0x6ffb (FLAGS_1)Flags: PIE 0x6ff9 (RELACOUNT) 1136 0x (NULL) 0x0 And then: Relocation section '.rela.dyn' at offset 0x3c170 contains 1136 entries: Offset Info Type Sym. ValueSym. Name + Addend 80042bf8 0008 R_X86_64_RELATIVE-7ffbc3a0 80042c08 0008 R_X86_64_RELATIVE-7ffbc300 80043c60 0008 R_X86_64_RELATIVE-7ffcaa06 80043c70 0008 R_X86_64_RELATIVE-7fffc3a0 80043d00 0008 R_X86_64_RELATIVE-7ffca920 80043d10 0008 R_X86_64_RELATIVE-7fff8670 80043ea0 0008 R_X86_64_RELATIVE-7ffca12c 80043ea8 0008 R_X86_64_RELATIVE-7ffca119 80043eb0 0008 R_X86_64_RELATIVE-7ffca113 80043eb8 0008 R_X86_64_RELATIVE-7ffca10f 80043ec0 0008 R_X86_64_RELATIVE-7ffca104 80043ec8 0008 R_X86_64_RELATIVE-7ffca0fb 80043ed0 0008 R_X86_64_RELATIVE-7ffca0e6 80043ed8 0008 R_X86_64_RELATIVE-7ffca0d7 ... continues ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #28 from H.J. Lu --- (In reply to mintsuki from comment #25) > (In reply to H.J. Lu from comment #23) > > (In reply to mintsuki from comment #21) > > > (In reply to H.J. Lu from comment #20) > > > > It turns out that static PIE with non-zero load address must have > > > > ET_EXEC: > > > > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=31799 > > > > > > > > Otherwise, there is no way for loader to tell if the dynamic section > > > > entries > > > > contain the relocated values for the load address or not. Since static > > > > PIE > > > > with non-zero load address must have ET_EXEC, PIE with non-zero load > > > > address > > > > also should have ET_EXEC. > > > > > > > > BTW, gold doesn't support static PIE and static PIE with non-zero load > > > > address > > > > generated by lld crashes with the fix glibc. > > > > > > At least in the context of making a kernel, gold does generate a > > > static-pie, > > > at least as printed out by the file command, and the output of readelf -a > > > looks similar to ld.bfd's -static -pie generation, even without the > > > -static > > > part. > > > > [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c > > [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c -fuse-ld=lld > > [hjl@gnu-cfl-3 tmp]$ gcc -static-pie x.c -fuse-ld=gold > > /usr/local/bin/ld.gold: --no-dynamic-linker: unknown option > > /usr/local/bin/ld.gold: use the --help option for usage information > > collect2: error: ld returned 1 exit status > > [hjl@gnu-cfl-3 tmp]$ > > This is not an issue if you call ld.gold manually as done by the kernel in > question (see above test case). > > I know that "you should not invoke the linker outside the driver" and I do > agree, but I do make an exception for linking bare metal, freestanding > stuff, as I like to have more control over the linking process. > > With that, I just didn't pass --no-dynamic-linker (as it is not supported by > gold, and the linker script makes it a non issue), and I didn't pass > -static, as frankly it seems to do nothing anyways when linking a -nostdlib -static is required for static PIE in user space to avoid linking in shared libraries. > > The test case above is too small to have any necessary relocation, but I > have another kernel using the same build system that has plenty of > R_X86_64_RELATIVE relocations and it works fine after Limine relocates it. I was not talking about R_XXX relocation. If dynamic tag entry address values contain unrelocated addresses (load address == 0), loader needs to add the load address to these addresses before using them to access their memory. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #29 from H.J. Lu --- (In reply to mintsuki from comment #27) > This is the aforementioned other kernel's readelf -d output: > > > Dynamic section at offset 0x46b70 contains 13 entries: > TagType Name/Value > 0x0004 (HASH) 0x8003c140 > 0x6ef5 (GNU_HASH) 0x8003c150 > 0x0005 (STRTAB) 0x8003c138 > 0x0006 (SYMTAB) 0x8003c120 > 0x000a (STRSZ) 1 (bytes) > 0x000b (SYMENT) 24 (bytes) > 0x0015 (DEBUG) 0x0 > 0x0007 (RELA) 0x8003c170 > 0x0008 (RELASZ) 27264 (bytes) > 0x0009 (RELAENT)24 (bytes) > 0x6ffb (FLAGS_1)Flags: PIE > 0x6ff9 (RELACOUNT) 1136 > 0x (NULL) 0x0 > Your kernel contains the relocated addresses in dynamic section since its load address != 0. Try load address == 0, these addresses will be different. You need to decide how to handle addresses like 0x0007 (RELA) 0x8003c170 Should you add load address to them or not? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #30 from mintsuki --- (In reply to H.J. Lu from comment #29) > (In reply to mintsuki from comment #27) > > This is the aforementioned other kernel's readelf -d output: > > > > > > Dynamic section at offset 0x46b70 contains 13 entries: > > TagType Name/Value > > 0x0004 (HASH) 0x8003c140 > > 0x6ef5 (GNU_HASH) 0x8003c150 > > 0x0005 (STRTAB) 0x8003c138 > > 0x0006 (SYMTAB) 0x8003c120 > > 0x000a (STRSZ) 1 (bytes) > > 0x000b (SYMENT) 24 (bytes) > > 0x0015 (DEBUG) 0x0 > > 0x0007 (RELA) 0x8003c170 > > 0x0008 (RELASZ) 27264 (bytes) > > 0x0009 (RELAENT)24 (bytes) > > 0x6ffb (FLAGS_1)Flags: PIE > > 0x6ff9 (RELACOUNT) 1136 > > 0x (NULL) 0x0 > > > > Your kernel contains the relocated addresses in dynamic section since its > load address != 0. Try load address == 0, these addresses will be different. > You need to decide how to handle addresses like > > 0x0007 (RELA) 0x8003c170 > > Should you add load address to them or not? Well, the way Limine has always dealt with this issue is: https://github.com/limine-bootloader/limine/blob/c204af454fc9c11b8ef3633664b6e03817c33ff1/common/lib/elf.c#L223 Basically, it tries to find a PHDR which contains the RELA section, and if it find it, it subtracts the PHDR's virtual address and adds its offset in order to find the offset of the RELA section inside the ELF file itself. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #31 from H.J. Lu --- (In reply to mintsuki from comment #30) > Basically, it tries to find a PHDR which contains the RELA section, and if > it find it, it subtracts the PHDR's virtual address and adds its offset in > order to find the offset of the RELA section inside the ELF file itself. In glibc, we know it is a static PIE. We relocate PT_DYNAMIC segment only if it is ET_DYN. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #32 from mintsuki --- (In reply to H.J. Lu from comment #31) > (In reply to mintsuki from comment #30) > > Basically, it tries to find a PHDR which contains the RELA section, and if > > it find it, it subtracts the PHDR's virtual address and adds its offset in > > order to find the offset of the RELA section inside the ELF file itself. > > In glibc, we know it is a static PIE. We relocate PT_DYNAMIC segment only if > it is ET_DYN. So what is the issue? And in any case, it doesn't feel right to me to have this behaviour in ld just to work around quirks of a specific ELF loader out of many. If anything, it needs to be handled in glibc, and the behaviour of ld should be reverted to match gold and lld. Just my opinion of course. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #33 from H.J. Lu --- (In reply to mintsuki from comment #32) > (In reply to H.J. Lu from comment #31) > > (In reply to mintsuki from comment #30) > > > Basically, it tries to find a PHDR which contains the RELA section, and if > > > it find it, it subtracts the PHDR's virtual address and adds its offset in > > > order to find the offset of the RELA section inside the ELF file itself. > > > > In glibc, we know it is a static PIE. We relocate PT_DYNAMIC segment only > > if > > it is ET_DYN. > > So what is the issue? And in any case, it doesn't feel right to me to have This is only after my patch: https://patchwork.sourceware.org/project/glibc/list/?series=34373 Currently glibc relocates PT_DYNAMIC segment unconditionally. > this behaviour in ld just to work around quirks of a specific ELF loader out > of many. > > If anything, it needs to be handled in glibc, and the behaviour of ld should > be reverted to match gold and lld. > The static PIE generated by ldd with non-zero load address won't work with glibc before and after my glibc fix. I will open an lld issue after glibc is fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #34 from mintsuki --- (In reply to H.J. Lu from comment #33) > (In reply to mintsuki from comment #32) > > (In reply to H.J. Lu from comment #31) > > > (In reply to mintsuki from comment #30) > > > > Basically, it tries to find a PHDR which contains the RELA section, and > > > > if > > > > it find it, it subtracts the PHDR's virtual address and adds its offset > > > > in > > > > order to find the offset of the RELA section inside the ELF file itself. > > > > > > In glibc, we know it is a static PIE. We relocate PT_DYNAMIC segment > > > only if > > > it is ET_DYN. > > > > So what is the issue? And in any case, it doesn't feel right to me to have > > This is only after my patch: > > https://patchwork.sourceware.org/project/glibc/list/?series=34373 > > Currently glibc relocates PT_DYNAMIC segment unconditionally. > > > this behaviour in ld just to work around quirks of a specific ELF loader out > > of many. > > > > If anything, it needs to be handled in glibc, and the behaviour of ld should > > be reverted to match gold and lld. > > > > The static PIE generated by ldd with non-zero load address won't work with > glibc before and after my glibc fix. I will open an lld issue after glibc > is fixed. I *strongly* disagree with this. Why are glibc implementation details dictating how ld.bfd operates? Where does it say non-0 load addresses for static-PIE/PIE are not allowed in the ELF specification? If it is allowed, why is ld.bfd not allowing me to do it despite Limine accepting this form of ELF files just fine? At least please consider adding a flag or linker script directive to manually set the ELF type... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #35 from H.J. Lu --- (In reply to mintsuki from comment #34) > > The static PIE generated by ldd with non-zero load address won't work with > > glibc before and after my glibc fix. I will open an lld issue after glibc > > is fixed. > > I *strongly* disagree with this. > > Why are glibc implementation details dictating how ld.bfd operates? Where This is how ELF works on Linux. > does it say non-0 load addresses for static-PIE/PIE are not allowed in the > ELF specification? If it is allowed, why is ld.bfd not allowing me to do it Static PIE isn't the part of ELF spec. There was a discussion: https://groups.google.com/g/generic-abi/c/mBKlSNldFW4/m/GRddmWGGBQAJ > despite Limine accepting this form of ELF files just fine? > > At least please consider adding a flag or linker script directive to > manually set the ELF type... That will generate the wrong static PIE with non-zero load address. You should check DF_1_PIE for PIE, not ET_DYN. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 --- Comment #36 from mintsuki --- (In reply to H.J. Lu from comment #35) > (In reply to mintsuki from comment #34) > > > > The static PIE generated by ldd with non-zero load address won't work with > > > glibc before and after my glibc fix. I will open an lld issue after glibc > > > is fixed. > > > > I *strongly* disagree with this. > > > > Why are glibc implementation details dictating how ld.bfd operates? Where > > This is how ELF works on Linux. Well, ELF is not Linux specific, though. > > > does it say non-0 load addresses for static-PIE/PIE are not allowed in the > > ELF specification? If it is allowed, why is ld.bfd not allowing me to do it > > Static PIE isn't the part of ELF spec. There was a discussion: > > https://groups.google.com/g/generic-abi/c/mBKlSNldFW4/m/GRddmWGGBQAJ > Then what is ld.bfd following, exactly? Just what Linux/glibc wants? How loosely specified (or not at all) can this be? > > despite Limine accepting this form of ELF files just fine? > > > > At least please consider adding a flag or linker script directive to > > manually set the ELF type... > > That will generate the wrong static PIE with non-zero load address. You > should > check DF_1_PIE for PIE, not ET_DYN. Limine already does that. The algorithm for determining whether an ELF is relocatable or not is at https://github.com/limine-bootloader/limine/blob/c204af454fc9c11b8ef3633664b6e03817c33ff1/common/lib/elf.c#L148-L181 If that was the case, you could've said it earlier and it would've saved the time for this discussion. I still do not like this, but it never caused issues to me or Limine or Limine users. It's just a purely technical argument, because ld.bfd diverged in behaviour compared to other linkers in a silly way. Now I see that this is done to make Linux/glibc happy, and thus unlikely to be fixed or reverted. -- You are receiving this mail because: You are on the CC list for the bug.
[GAS bug] Typo in texi docs of GNU Assembler
Hello, I've just spotted a typo in GNU Assembler documentation: File path: gas/doc/as.texi line text --- 938 @item --reduce-memory-overheads 939 Ignored. Supported for compatibility with tools that apss the same option to 940 both the assembler and the linker. This should reed "pass". Thanks for a great software package (especially objdump). Jiří Wolker
[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
Fangrui Song changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||i at maskray dot me
Resolution|FIXED |---
--- Comment #37 from Fangrui Song ---
I agree with mintsuki . The "-pie -Ttext-segment=non-zero => ET_EXEC" hack
should not be needed.
>From https://sourceware.org/pipermail/binutils/2013-December/083381.html
> Linker sets e_type in ELF header to ET_DYN for -pie -Ttext-segment=0xXXX.
> When I added -Ttext-segment=0xXXX, one goal was to load
> small model executable above 4GB on Linux/x86-64, which
> was done with -pie -Ttext-segment=0xXXX. But -pie sets
> e_type in ELF header to ET_DYN and kernel may ignore
> p_vaddr in ELF header to load ET_DYN binary at a random
> address. This patch changes ld to set e_type in ELF header
> to ET_EXEC if the first PT_LOAD segment has non-zero
> p_vaddr. If this is unacceptable as generic ELF change,
> I can make it specific to x86.
Was the intention for the following command to load the text segment at an
address >= 0x6000 ?
```
% cat a.c
#include
int main() { printf("%p\n", main); }
% gcc -pie -Wl,-no-pie a.c -fuse-ld=bfd
-Wl,--no-relax,-Ttext-segment=0x6000 -o a
% ./a
0x60001139
% ./a
0x60001139 # no ASLR
```
Changing ET_DYN to ET_EXEC fulfills the address requirement but disables ASLR.
Is it intentional?
I added `--no-pie` to GNU ld in 2021:
https://sourceware.org/cgit/binutils-gdb/commit/?id=e8f6c2a5bab10b039a12b69a30a8248c91161e11
, with which we can do the following instead. (GNU ld also needs `--no-relax`
while lld doesn't).
```
% gcc -pie a.c -fuse-ld=bfd
-Wl,--no-pie,--no-relax,-Ttext-segment=0x6000 -o a
% ./a
0x60001139
% ./a
0x60001139
```
--
You are receiving this mail because:
You are on the CC list for the bug.
