mirrors/zig
1
0
Fork 0
mirror of https://codeberg.org/ziglang/zig.git synced 2025-12-06 13:54:21 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Elf: switch link order of libcompiler_rt and libc

Browse source 
Given `main.go`:

    package main
    import  _ "os/user"
    func main() {}

Compiling it to linux/arm64:

    $ CGO_CFLAGS='-O0' GOOS=linux GOARCH=arm64 CGO_ENABLED=1 CC="zig cc -target aarch64-linux-gnu.2.28" go build main.go

Results in this error:

    runtime/cgo(.text): unknown symbol memset in callarm64
    runtime/cgo(.text): unknown symbol memset in callarm64
    runtime/cgo(.text): relocation target memset not defined

In the midst of intermediate compilations files we can see this commmand:

    ld.lld -o _cgo_.o <...> /tmp/go-build206961058/b043/_x009.o <...> ~/.cache/zig/.../libcompiler_rt.a <...> ~/.cache/.../libc.so.6

`_x009.o` needs memset:

    $ readelf -Ws ./b043/_x009.o | grep memset
        22: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND memset

Both `libcompiler_rt.a` and `libc.so.6` provide it:

    $ readelf -Ws ~/.cache/zig/.../libcompiler_rt.a | grep memset
       870: 0000000000000000   318 FUNC    WEAK   DEFAULT  519 memset

    $ readelf -Ws ~/.cache/zig/.../libc.so.6 | grep -w memset
       476: 000000000001d34c     0 FUNC    GLOBAL DEFAULT    7 memset@@GLIBC_2.2.5

Since `libcompiler_rt.a` comes before libc in the linker line, the
resulting `_cgo_.o` still links to a weak, unversioned memset:

    $ readelf -Ws ./b043/_cgo_.o | grep -w memset
        40: 000000000022c07c   160 FUNC    WEAK   DEFAULT   14 memset
       719: 000000000022c07c   160 FUNC    WEAK   DEFAULT   14 memset

Since the final linking step is done by Golang's linker, it does not
know of `libcompiler_rt.a`, and fails to link with the error message
above. However, Go linker does recognize memset from glibc. If we
specify an `-lc` equivalent before the `libcompiler_rt.a`, it will link
to memset from libc:

    $ readelf -Wa ./b043/_x009.o |grep memset
        14: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memset@GLIBC_2.17 (2)
       157: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memset@GLIBC_2.17

... and then `main.go` will compile+link successfully.

Why doesn't Go linker take memset from glibc? An educated guess: Go
determines whether to link with glibc from what the program asks (I
presume `.dynsym`). Since `memset` is no longer attributed to glibc, Go
skips linking to glibc altogether.

Bonus question: curious why `-O0` is necessary? Because when
optimizations are enabled (the default), the C compiler replaces
`memset` function call with plain `stp` instructions (on aarch64).
This commit is contained in:
Motiejus Jakštys 2022-12-16 09:29:09 +02:00 • committed by Andrew Kelley
parent bcc2fb66f3
commit c841f52fcb
1 changed files with 7 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
src/link/Elf.zig
View file

@ -1698,11 +1698,6 @@ fn linkWithLLD(self: *Elf, comp: *Compilation, prog_node: *std.Progress.Node) !v
try argv.append(ssp.full_object_path);
}
// compiler-rt
if (compiler_rt_path) |p| {
try argv.append(p);
}
// Shared libraries.
if (is_exe_or_dyn_lib) {
const system_libs = self.base.options.system_libs.keys();
@ -1781,6 +1776,13 @@ fn linkWithLLD(self: *Elf, comp: *Compilation, prog_node: *std.Progress.Node) !v
}
}
// compiler-rt. Since compiler_rt exports symbols like `memset`, it needs
// to be after the shared libraries, so they are picked up from the shared
// libraries, not libcompiler_rt.
if (compiler_rt_path) |p| {
try argv.append(p);
}
// crt postlude
if (csu.crtend) |v| try argv.append(v);
if (csu.crtn) |v| try argv.append(v);