[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #21 from Rui Ueyama --- I fixed several issues in mold related to POWER10 compatibility, and all its unit tests pass on gcc120! I also confirmed that mold can now bootstrap itself with `-mcpu=power10`. So I believe it's now usable on POWER10 machines.
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #20 from Rui Ueyama --- Last time I tried, mold-produced binaries crash on a real POWER10 machine, but I couldn't debug it due to some issue (gdb's issue or something but I don't remember exactly what that was.) Let me try again when I have time.
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #12 from Rui Ueyama --- > Hmm, if you configure the cross target with --with-ld=ld.mold does that then > work (when not specifying -fuse-ld=mold)? Sorry, I don't know, but in either case, that wouldn't solve the user-facing problem when `-fuse-ld=mold` is explicitly passed. > I suppose we could adjust how the driver(?) behaves, noting whether the linker > is multi-arch or not and at least allowing as fallback to use the "host" > specified linker. Yes, please :)
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #10 from Rui Ueyama --- > This is only a problem when using a cross gcc, so why should mold proactively > create symlinks for dozens of targets when mold is installed? It's because there are too many and we don't have an exhaustive list of all possible triples. In particular, the vendor part of a triple (e.g. "none" in "arm-none-eabi") can be anything IIUC, so we can't make an exhaustive list of all triples. > It seems to me that a single symlink only needs to be created by the person > building the cross-gcc, and installed alongside $target-gcc as part of that > toolchain. This is not mold's problem, and could just be documented as part > of gcc's installation docs. That's the correct solution if mold is bundled as part of the cross toolchain. But if a user of the cross gcc toolchain wanted to use the system-installed mold, they explicitly create a symbolic link in a $PATH by themselves at this moment. I think that's pretty inconvenient. > Although it probably does make sense for gcc to just fallback to using > ld.mold without the target prefix. Yeah, that's exactly what I want...
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #8 from Rui Ueyama --- Sure, I agree with that. But would there be any problem if gcc, after failing to find `-mold` and `mold` in the embedded toolchain's directory, looks for `ld.mold` in the $PATH?"
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #6 from Rui Ueyama --- Since mold supports all targets by a single executable, it doesn't make much sense to install one mold executable for each embedded toolchain. So if we want to keep the current gcc's lookup mechanism for `ld` executable, we want to install mold somewhere in the system and install a symlink for each target, and that's not compatible with relocatable emddeded toolchain directory. We need to adjust the realpath of a symlink to point to the mold executable file. All in all, the problem wouldn't exist at all if gcc just looks for `ld.mold`? (I'm not suggesting making a change to the default behavior; I'd do that only if `-fuse-ld=mold` or `-fuse-ld=lld` is givne.)
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #4 from Rui Ueyama --- > More likely the scripts which build the full toolchains directories should be > creating the symbolic links instead of mold itself. So the package manager create a `-ld.mold` as a symlink to `mold` if mold is installed? Or, should it create a `-ld.mold` unconditionally as a symlink to `/usr/bin/mold`? If the latter, what if the user build mold themselves and install it under `/usr/local/bin`?
[Bug driver/111605] Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 --- Comment #2 from Rui Ueyama --- I can make a change to the `make install` rule of the mold linker to install bunch of symbolic links, but can we enumerate all possible triples? For example, I wasn't aware that `arm-none-eabi` was a valid triple. If I enumerate _all_ possible triples, wouldn't I end up with installing hundreds of symlinks? And the tons of symbolic links wouldn't serve any meaningful purpose because mold just ignores argv[0].
[Bug c++/111605] New: Cross compilation doesn't work with `-fuse-ld=mold`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111605 Bug ID: 111605 Summary: Cross compilation doesn't work with `-fuse-ld=mold` Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- When I pass `-fuse-ld=mold` to a gcc cross compiler, gcc searches for `ld.mold` from the crosstool's bin directories and then looks for `-ld.mold` from $PATH. Here is a gcc's strace when invoked with `-fuse-ld=mold`. [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/11/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/11/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/11/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/gcc-cross/riscv64-linux-gnu/11/../../../../riscv64-linux-gnu/bin/ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/.cargo/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/.local/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/.cabal/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/prefix/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/bin/qemu/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/lib/ccache/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/golang/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/.mozbuild/node/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/home/ruiu/bin/depot_tools/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/local/sbin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/local/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/sbin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/sbin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/games/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/usr/local/games/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) [pid 3905484] newfstatat(AT_FDCWD, "/snap/bin/riscv64-linux-gnu-ld.mold", 0x7ffdd5a491a0, 0) = -1 ENOENT (No such file or directory) This behavior is appropriate for BFD linker which has one executable for each cross target. However, it's incorrect for the mold linker because mold supports all targets by a single executable. Therefore, when gcc searches mold from $PATH, it should look for just `ld.mold`, without the triple. The same is true for LLD. The link to the upstream bug: https://github.com/rui314/mold/issues/1114
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #11 from Rui Ueyama --- I'll try to add a POWER10 support to mold using Qemu.
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #9 from Rui Ueyama --- I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI because I didn't have an access to a POWER10 machine and therefore couldn't verify the correctness of my implementation.
[Bug target/105305] ARM32: gcc does not pass all library directories to linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105305 --- Comment #3 from Rui Ueyama --- By other ld's, what linkers did you have in your mind? If lld, mold and gold don't hard code /usr and /usr/lib, then the only remaining linker is GNU ld. It doesn't seem like POSIX says about the default library search paths. I don't believe POSIX even mandates the existence of /usr and /usr/lib. macOS doesn't have such directories, but IIUC macOS at least one point in the past certified as POSIX compliant.
[Bug c/106835] [i386] Taking an address of _GLOBAL_OFFSET_TABLE_ produces a wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835 --- Comment #6 from Rui Ueyama --- If it silently produces a value that doesn't make sense, shouldn't we ban the use of the variable or at least show a warning?
[Bug c++/106834] GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834 --- Comment #3 from Rui Ueyama --- Here is my gcc -S output: $ gcc-12 -S -o- foo.c .file "foo.c" .text .section.rodata .LC0: .string "%lx" .text .globl main .type main, @function main: .LFB0: .cfi_startproc endbr64 pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 leaq_GLOBAL_OFFSET_TABLE_(%rip), %rax movq%rax, %rsi leaq.LC0(%rip), %rax movq%rax, %rdi movl$0, %eax callprintf@PLT movl$0, %eax popq%rbp .cfi_def_cfa 7, 8 ret .cfi_endproc
[Bug c/106835] New: [i386] Taking an address of _GLOBAL_OFFSET_TABLE_ produces a wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
Bug ID: 106835
Summary: [i386] Taking an address of _GLOBAL_OFFSET_TABLE_
produces a wrong value
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rui314 at gmail dot com
Target Milestone: ---
On i386, _GLOBAL_OFFSET_TABLE_ should reference the location of .got.plt.
However, the following piece of code prints out a bogus value:
```
$ cat foo.c
#include
extern char _GLOBAL_OFFSET_TABLE_[];
char *ptr = _GLOBAL_OFFSET_TABLE_;
int main() {
printf("%lx\n", (unsigned long)ptr);
}
$ i686-linux-gnu-gcc-12 -m32 -c foo.c
$ i686-linux-gnu-gcc-12 -m32 -o foo foo.o
$ ./foo
ffd0
```
This is because the relocation for .data is of type R_386_GOTPC. It should be
R_386_32.
```
$ readelf -r foo.o
Relocation section '.rel.text' at offset 0x234 contains 5 entries:
Offset InfoTypeSym. Value Symbol's Name
0010 0802 R_386_PC32 __x86.get_pc_thunk.ax
0015 060a R_386_GOTPC _GLOBAL_OFFSET_TABLE_
001b 0509 R_386_GOTOFF ptr
0025 0309 R_386_GOTOFF .rodata
002d 0904 R_386_PLT32 printf
Relocation section '.rel.data.rel' at offset 0x25c contains 1 entry:
Offset InfoTypeSym. Value Symbol's Name
060a R_386_GOTPC _GLOBAL_OFFSET_TABLE_
```
I found this bug when writing a test for the mold linker.
Related to: https://github.com/rui314/mold/issues/693
[Bug c++/106834] GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834 --- Comment #1 from Rui Ueyama --- It was originally reported to the mold linker. For the record, here is the link to the original issue: https://github.com/rui314/mold/issues/693
[Bug c++/106834] New: GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
Bug ID: 106834
Summary: GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rui314 at gmail dot com
Target Milestone: ---
I think I found a GCC bug. Here is how to reproduce the issue:
```
$ cat foo.c
#include
extern char _GLOBAL_OFFSET_TABLE_[];
int main() {
printf("%lx", (unsigned long)_GLOBAL_OFFSET_TABLE_);
}
$ gcc-12 -c -fPIC foo.c
$ gcc -o foo foo.o
$ ./foo
Illegal instruction (core dumped)
```
The resulting executable crashes with an illegal instruction because the linker
overwrites instructions with an immediate. Take a look at the following objdump
output:
```
$ objdump -dr foo.o
foo.o: file format elf64-x86-64
Disassembly of section .text:
:
0: f3 0f 1e fa endbr64
4: 55 push %rbp
5: 48 89 e5mov%rsp,%rbp
8: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# f
b: R_X86_64_GOTOFF64_GLOBAL_OFFSET_TABLE_-0x4
f: 48 89 c6mov%rax,%rsi
12: 48 8d 05 00 00 00 00lea0x0(%rip),%rax# 19
15: R_X86_64_PC32 .rodata-0x4
19: 48 89 c7mov%rax,%rdi
1c: b8 00 00 00 00 mov$0x0,%eax
21: e8 00 00 00 00 call 26
22: R_X86_64_PLT32 printf-0x4
26: b8 00 00 00 00 mov$0x0,%eax
2b: 5d pop%rbp
2c: c3 ret
```
At offset 0xb, there's a relocation of type R_X86_64_GOTOFF64. GOTOFF64 makes
the linker to write a 8-bytes offset to a given symbol. However, the
instruction for that relocation is just `mov` and not `movabs`, so the
subsequent 4-bytes are accidentally overwrote byt eh linker.
[Bug ipa/105625] Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 --- Comment #5 from Rui Ueyama --- Cool! We'll add a `.llvm_addrsig` support to binutils and get back to you guys.
[Bug ipa/105625] Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 --- Comment #3 from Rui Ueyama --- I think we can implement the `.addrsig` support to the assembler, but I wonder if GCC will support it once the GNU assembler gains the feature?
[Bug c++/105625] New: Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 Bug ID: 105625 Summary: Support .llvm_addrsig section Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- This is a feature request to implement an LLVM-compatible feature so that linkers can optimize GCC-generated object files as much as they can currently do for LLVM-generated ones. Disclaimer: I'm the creator of the mold linker (https://github.com/rui314/mold) Background: GNU gold and LLVM lld have a feature so-called Identical Code Folding (ICF). ICF finds functions that happen to be compiled to the exact same machine code to merge them. This is known as an effective optimization especially for C++ programs, since a function template tend to be compiled to the same machine code for different types. For example, `std::vector` and `std::vector` are likely to be instantiated to the exact same machine code, even though they will get different mangled names. ICF can merge such code. There's one caveat though. ICF is not a "safe" optimization. In C/C++, two function pointers are equal if and only if they are pointing the same function. For example, if you have two different functions `foo` and `bar`, `foo == bar` will never be true. ICF breaks this assumption if it merges `foo` and `bar`, as after merging, they will be at the same address. That said, if you know that there's no code that takes a pointer of `foo` or `bar`, it is safe to merge `foo` with `bar`, since it's impossible to compare pointers without taking their addresses. gold and lld implement a "safe" ICF with that observation. The gold's safe ICF merges only C++ constructors and destructors. Since there's no way to obtain a pointer of a ctors or dtors within the C++ language spec, they are always safe to merge. gold identifies ctors and dtors by reading their mangled names. What gold does is safe but too conservative as it cannot merge other functions. The lld's safe ICF works with an LLVM feature. Since mid-2018, LLVM emits a `.llvm_addrsig` section to all object files by default. That section contains symbol indices whose addresses are taken. Using this table, lld can merge functions more aggressively than gold can do. Recently, we implemented an lld-compatible safe ICF to mold. It works great, but it doesn't work with GCC as GCC does not produce `.llvm_addrsig` sections. Feature request: Can GCC produce the `.llvm_addrsig` section just like LLVM does? It will make GCC-generated executables on par with LLVM-generated ones with ICF in terms of file size. References: Here is an explanation of the `.llvm_addrsig` section: https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table This is a patch to have added the feature to LLVM: https://reviews.llvm.org/D47744 Here is an upstream issue for mold: https://github.com/rui314/mold/issues/484
[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239 --- Comment #14 from Rui Ueyama --- I see. I think I'm convinced.
[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239 --- Comment #12 from Rui Ueyama --- I mean setting STV_HIDDEN visibility to a symbol prevents it to be visible from any ELF binaries than itself, which may resolve your concern. I may be missing something though.
[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239 --- Comment #11 from Rui Ueyama --- You can make it a global, hidden symbol, can't you?
[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239 --- Comment #9 from Rui Ueyama --- Thanks Jukub for the description. I'll try to implement it to mold. One question though. Why doesn't gcc create a weak symbol wm4.stdio.h.24.5c1b97eef3c86b7a2549420f69f4f128 at the beginning of each wm4.stdio.h.24.5c1b97eef3c86b7a2549420f69f4f128 section and always use that symbol instead of referring the beginning of the section using the section symbol? The ELF spec says that no one should refer any comdat members directly and instead refer them via symbols, so the current GCC's behavior violates the spec if I understand it correctly.
[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239 --- Comment #7 from Rui Ueyama --- Note that the latter should be easier to implement because finding a matching section in a prevailing comdat group for a deduplicated section may not be trivial.
[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239 Rui Ueyama changed: What|Removed |Added CC||rui314 at gmail dot com --- Comment #6 from Rui Ueyama --- I can add a support to mold so that mold works for this test case. I'm not 100% sure what's the correct behavior though. It looks like we should redirect references to dead comdat members to prevailing ones. But is there any guarantee that all COMDAT members have the exact same set of members? We deduplicate COMDAT groups just by looking at their group names and don't compare their members. Or, can we just leave `.debug_macros` sections even if they are in deduplicated COMDAT groups?
[Bug c/105305] New: ARM32: gcc does not pass all library directories to linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105305 Bug ID: 105305 Summary: ARM32: gcc does not pass all library directories to linker Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- I'm the author of the mold linker (https://github.com/rui314/mold). As far as I know, gcc always passes all library paths to the linker by -L, but I got a bug report that that's not the case on ARM32. It is reported that gcc does not pass some obvious paths such as `-L/usr` or `-L/usr/lib`. The code to explicitly exclude "obvious" directories is here: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.cc;h=bb07cc244e30fbeccc701816db888f497d65eb08;hb=refs/heads/master#l7931 mold and LLVM lld don't have the notion of the default search paths for the sake of build reproducibility. They guarantee that as long as you pass the exact same command line options and input files, the linkers behave exactly the same regardless of the host machine (in LLD, that's guaranteed even across Unix and Windows.) That helps us a lot when we do cross compilation. So, can gcc pass all library paths to the linker on ARM32? https://github.com/rui314/mold/issues/336
[Bug target/105172] RV64: gcc generates R_RISCV_ALIGN with a non-power-of-two value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105172 Rui Ueyama changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Rui Ueyama --- I didn't understand the correct semantics of this type of relocation. Please disregard this issue. Sorry for the noise.
[Bug c/105172] New: RV64: gcc generates R_RISCV_ALIGN with a non-power-of-two value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105172 Bug ID: 105172 Summary: RV64: gcc generates R_RISCV_ALIGN with a non-power-of-two value Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- It is reported against the mold linker (https://github.com/rui314/mold/issues/419), but I believe it's GCC"s bug. It looks like GCC sometimes create a R_RISCV_ALIGN relocation with a non-power-of-two requirement alignment, as you can see in the above bug report. That simply doesn't make sense and strongly suggests that something is not working as intended in GCC. I believe all R_RISV_ALIGN relocations have a power-of-two value.
[Bug bootstrap/104887] [9/10/11 only] mold linker is not detected properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104887 --- Comment #2 from Rui Ueyama --- What kind of regression are you worry about?
[Bug bootstrap/104887] New: mold linker is not detected properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104887 Bug ID: 104887 Summary: mold linker is not detected properly Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- GCC 11.2.0 fails to bootstrap if `ld` is `ld.mold` (https://github.com/rui314/mold). It is because gcc's configure script has no idea as to what `ld.mold` is and consider it as a very old linker that doesn't support COMDAT. GCC 12's configure script correctly recognizes mold. Can you backport the fix to support mold in the GCC 11 series?
[Bug c++/104708] RV64: gcc does not pass all library directories to linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104708 --- Comment #1 from Rui Ueyama --- Here is the link to the original bug report: https://github.com/rui314/mold/issues/358
[Bug c++/104708] New: RV64: gcc does not pass all library directories to linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104708 Bug ID: 104708 Summary: RV64: gcc does not pass all library directories to linker Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- I'm the author of the mold linker (https://github.com/rui314/mold). As far as I know, gcc always passes all library paths to the linker by -L, but I got a bug report that that's not the case on RV64. It is reported that gcc does not pass some obvious paths such as `-L/usr` or `-L/usr/lib`. Can gcc pass all library paths to the linker on RV64?
