[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #4 from Nick Clifton --- (In reply to Rostislav Krasny from comment #3) > In case you can't guarantee the "core.sharedRepository" configuration > property was set properly before the src-release.sh was ran you can, in > addition to setting umask in its beginning, also set the > "core.sharedRepository" Git configuration property near the umask command > and right after that run 'git reset --hard'. You can also add some check > that there is no uncommitted changes before the 'git reset --hard' is > actually run. Maybe this is the best solution. OK - would you like to submit a patch to that affect please ? (Your git-fu is obviously stronger than mine ... :-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31761] Linker deletes output file even if linking fails
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 --- Comment #7 from Nick Clifton --- (In reply to Peter Damianov from comment #5) > Just to be completely clear, the command is incorrect, but the way ld reacts > to the mistake is the problem. In this case, the "file.c" will be deleted, > the user has potentially lost a file, and day ruined. I think refusing to > delete output here is the correct and preferable thing to do. It may seem callous, but if you are using command line tools to build programs then I would argue that a certain level of competence is expected, and that loosing a source file to a silly mistake is actually a useful lesson. But maybe a compromise solution can be reached here. As Alan pointed out, setting the output file name to the name of an existing source file is going to cause problems regardless of whether the link succeeds or fails. So maybe the correct thing to do is to have the "-o " option fail if the output name matches the name of an existing file *and* that name matches a pattern of known source files (eg *.[cChosS] *.cpp) ? What do you think ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31761] Linker deletes output file even if linking fails
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 --- Comment #8 from Peter Damianov --- (In reply to Alan Modra from comment #6) > I agree with Nick's comment. Consider too that if the link had succeeded, > your source file would have been overwritten (assuming of course that write > access was allowed to the file). I'm aware. But this is less likely to happen, perhaps maybe only when linking libraries that do expect to provide their own main (like SDL). It would be a lot harder to make this mistake for that case. If you miss out a source file your code is usually not going to link anyway. (In reply to Nick Clifton from comment #7) > (In reply to Peter Damianov from comment #5) > > Just to be completely clear, the command is incorrect, but the way ld reacts > > to the mistake is the problem. In this case, the "file.c" will be deleted, > > the user has potentially lost a file, and day ruined. I think refusing to > > delete output here is the correct and preferable thing to do. > > It may seem callous, but if you are using command line tools to build > programs then I would argue that a certain level of competence is expected, > and that loosing a source file to a silly mistake is actually a useful > lesson. I would argue there are better ways to teach that lesson. I think it is important for users to be able to learn how to invoke gcc without risking demotivating problems like these. > > But maybe a compromise solution can be reached here. As Alan pointed out, > setting the output file name to the name of an existing source file is going > to cause problems regardless of whether the link succeeds or fails. So > maybe the correct thing to do is to have the "-o " option fail if the > output name matches the name of an existing file *and* that name matches a > pattern of known source files (eg *.[cChosS] *.cpp) ? I tried to implement this in the gcc driver and had some trouble, but I had to be more careful then because flags like -E and -S needed to be considered. I think this might also run the risk of maybe breaking some weird configure scripts. Just as a test, I tried: ls /usr/bin/*.* To see if there was anything it could affect The most common case of having a suffix was simply a version number (e.g. x86_64-pc-linux-gnu-gcc-14.1.1, python3.12) Next was .sh and .pl mkfs had some instances, like mkfs.ext4, mkfs.vfat And last were the linkers, ld.mold, ld.bfd, There wasn't anything this would break, but of course it's a small subset of what is out there. > > What do you think ? I think going all this way is not necessary, and simply leaving the file alone in the case of the link failing would be enough to cover most cases. And it's already tested/implemented by other linkers. But, this suggestion of "filename heuristics" could also work. If you think it's worth it, go for it. -- 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 #66 from mintsuki --- (In reply to Fangrui Song from comment #65) > > > Changing ET_DYN to ET_EXEC fulfills the address requirement but disables > > > ASLR. > > > Is it intentional? > > > > That's my understanding of reading the -Ttext-segment documentation. The > > question is whether we relax the semantic to have it as a minimum address > > or define it as the expected address (thus disabling ASLR as a > > consequence). > > > > I don't have a strong opinion, but currently, Linux only enforces the > > former (I think it is the main reason this makes some sense) so we will > > need to discuss with kernel developers the expected semantics. > > If there is a strong need for the address requirement (>=p_vaddr), Linux > kernel and glibc have the capability to implement it. > However, this alone does not justify keeping the ld hack that sets ET_EXEC > for -pie -Ttext-segment=$non_zero. > > > -Ttext-segment=0x6000 should create a binary which is guaranteed to > > be > > loaded at 0x6000. > > -Ttext-segment sets the address of the first byte of the text segment, which > likely influences the p_vaddr member of a PT_LOAD segment. > When e_type is ET_EXEC, this address is also the virtual address of the > first memory area. > However, if e_type is ET_DYN, there's no guarantee of this address, and > fulfilling this request is left to the discretion of the loaders. > > Since ld offers the -no-pie flag, there's no need for a workaround to make > -pie behave similarly. > (In addition, DF_1_PIE with ET_EXEC is very odd.) Indeed. This is not what lld does, at all. Also the statement that PIE executables with non-0 load addresses would misbehave if relocated is also something that I cannot wrap my head around, especially since I have been relocating these for years without issues. Those generated by lld, gold, and bfd, the former 2 of which have absolutely no issue generating a PIE with non-0 load address. Also I will change the title of the bug report from static PIE to PIE, because the PIE having or not having dynamically linked libraries is irrelevant to the issue at hand. > > If a user desires both address>=0x6000 && ASLR, this could be > achieved if ET_DYN is used and loaders satisfy the address requirement. > However, retaining the ET_EXEC hack in ld would prevent the fulfillment of > this goal. > > > PIE is the only way to create a small mode executable loaded at > > 0x6000. > > This is an oversimplification. > > The -mcmodel= flag imposes specific code generation restrictions that allow > relocatable files to be used in certain address space layouts after linking. > While it's (almost) a sufficient condition, it's not a necessary one. > > Achieving high-address functionality doesn't necessitate -mcmodel=large. For > instance, you can use PIC symbol addressing (combining -mcmodel=small -fpie > with non-preemptible symbols) to achieve the same result. > If your code is larger than 2GiB, you can even use range extension thunks. > > https://maskray.me/blog/2023-05-14-relocation-overflow-and-code-models#x86- > 64-code-models > > Similarly, for a function call, we no longer assume that the address of > the function or its PLT entry is within the ±2GiB range from the program > counter, so call callee cannot be used. > > Actually, call callee can still be used if we implement range extension > thunks in the linker, unfortunately GCC/GNU ld did not pursue this direction. > > > There are 2 issues with -mcmodel=large: > > > > 1. Since there are no -mcmodel=large run-time libraries, you can't use > > -mcmodel=large > > to create any meaningful binaries. > > 2. -mcmodel=large performance is much slower. > > True. (1) is an ecosystem issue with -mcmodel=large. > However, this point is unrelated to the ld ET_EXEC hack. > > > I think BFD can use the emulation (-m) option for this, since, for > > instance, gcc will pass -maarch64linux for aarch64-linux-gnu. > > I don't think this is necessary. > > `-pie -Wl,-no-pie` works today (lld doesn't even need `--no-relax`). > Therefore, there isn't a strong argument retaining the ET_EXEC hack. > > % gcc -pie -Wl,-no-pie a.c -fuse-ld=bfd > -Wl,--no-relax,-Ttext-segment=0x6000 -o a > % ./a > 0x60001139 > % ./a > 0x60001139 # no ASLR -- 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 PIEs when load address is non-0
https://sourceware.org/bugzilla/show_bug.cgi?id=31795 mintsuki changed: What|Removed |Added Summary|ld.bfd makes ELFs of type |ld.bfd makes ELFs of type |ET_EXEC for static PIEs |ET_EXEC for PIEs when load |when load address is non-0 |address is non-0 -- 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 Andrey Sotnikov changed: What|Removed |Added CC||usaonmonday at gmail dot com --- Comment #11 from Andrey Sotnikov --- After my system updated (I suspect glibc 2.39), I started seeing these errors during compilation: /home/user/binutils-env/bin/ld: error: .libs/synctrace.o: multiple definition of 'pthread_cond_wait' /home/user/binutils-env/bin/ld: .libs/synctrace.o: previous definition here /home/user/binutils-env/bin/ld: error: .libs/synctrace.o: multiple definition of 'pthread_cond_timedwait' /home/user/binutils-env/bin/ld: .libs/synctrace.o: previous definition here /home/user/binutils-env/bin/ld: error: .libs/synctrace.o: multiple definition of 'pthread_join' /home/user/binutils-env/bin/ld: .libs/synctrace.o: previous definition here /home/user/binutils-env/bin/ld: error: .libs/synctrace.o: multiple definition of 'sem_wait' /home/user/binutils-env/bin/ld: .libs/synctrace.o: previous definition here collect2: error: ld returned 1 exit status The culprit commit is https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=66f76c545b293f8b89fef0f996a3a48fa59fae61 Checked with GCC 13 and 14. The failing command line was gcc -shared -fPIC -DPIC .libs/synctrace.o -march=native -mtune=native -Wl,--version-script -Wl,../../../binutils-gdb/gprofng/libcollector/libgprofng.ver -Wl,--no-as-needed -Wl,-lrt -Wl,-ldl -Wl,-soname -Wl,libgp-sync.so -o .libs/libgp-sync.so -fuse-ld=bfd does help. -- 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 #12 from Vladimir Mezentsev --- It looks like your ld is old. See H.J. Lu's comments/fixes for ld above. -- 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 #13 from Andrey Sotnikov --- $ ld --version GNU gold (GNU Binutils 2.41.50) 1.16 Copyright (C) 2023 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. -- 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 #14 from Vladimir Mezentsev --- I think H.J. Lu's fixes are in 2.42. Try downloading version 2.42 or building the latest version of the binutils-gdb repository. -- 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 #15 from Andrey Sotnikov --- $ ld --version GNU gold (GNU Binutils 2.42.0.20240530) 1.16 Same result. The full ld's command line captured with strace: /home/user/binutils-env/bin/ld -plugin /home/user/gcc-env/lib/gcc/x86_64-linux-gnu/14/liblto_plugin.so -plugin-opt=/home/user/gcc-env/lib/gcc/x86_64-linux-gnu/14/lto-wrapper -plugin-opt=-fresolution=/tmp/cc1r18nR.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -shared -o .libs/libgp-sync.so /lib/crti.o /home/user/gcc-env/lib/gcc/x86_64-linux-gnu/14/crtbeginS.o -L/home/user/gcc-env/lib/gcc/x86_64-linux-gnu/14 -L/lib -L/usr/lib -L/home/user/gcc-env/lib -L/home/user/binutils-env/lib .libs/synctrace.o --version-script ../../../binutils-gdb/gprofng/libcollector/libgprofng.ver --no-as-needed -lrt -ldl -soname libgp-sync.so -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /home/user/gcc-env/lib/gcc/x86_64-linux-gnu/14/crtendS.o /lib/crtn.o -- You are receiving this mail because: You are on the CC list for the bug.
