clang -pg produces invalid executable on FreeBSD

[Quuxplusone]

Bugzilla Link	PR48165
Status	NEW
Importance	P normal
Reported by	Oleg Derevenetz (oleg-derevenetz@yandex.ru)
Reported on	2020-11-12 15:35:10 -0800
Last modified on	2020-11-14 09:16:39 -0800
Version	10.0
Hardware	PC FreeBSD
CC	blitzrakete@gmail.com, dgregor@apple.com, dimitry@andric.com, emaste@freebsd.org, erik.pilkington@gmail.com, i@maskray.me, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Consider the following program:

$ cat test.c
#include <stdio.h>

int main()
{
    printf("OK\n");
}

When built using the following command:

$ clang -pg test.c

the following binary is produced:

$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically
linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.2, FreeBSD-style, with
debug_info, not stripped

(note the "interpreter /libexec/ld-elf.so.1" part).

Once launched, it crashes inside ld-elf.so.1 with SIGSEGV:

$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/usr/home/oleg/tmp/pg/a.out' (x86_64).
(lldb) run
Process 872 launching
Process 872 launched: '/usr/home/oleg/tmp/pg/a.out' (x86_64)
Process 872 stopped
* thread #1, name = 'a.out', stop reason = signal SIGSEGV: invalid address
(fault address: 0x0)
    frame #0: 0x00000008002a3ab0
->  0x8002a3ab0: movq   (%r15), %rdx
    0x8002a3ab3: cmpq   $0x6fffffef, %rdx         ; imm = 0x6FFFFFEF
    0x8002a3aba: jg     0x8002a3b10
    0x8002a3abc: cmpq   $0x21, %rdx
(lldb) disassemble
->  0x8002a3ab0: movq   (%r15), %rdx
    0x8002a3ab3: cmpq   $0x6fffffef, %rdx         ; imm = 0x6FFFFFEF
    0x8002a3aba: jg     0x8002a3b10
    0x8002a3abc: cmpq   $0x21, %rdx
    0x8002a3ac0: ja     0x8002a3ba6
    0x8002a3ac6: movslq (%r12,%rdx,4), %rax
    0x8002a3aca: addq   %r12, %rax
    0x8002a3acd: jmpq   *%rax
(lldb)

Disassembled code above is apparently from ld-elf.so.1/_rtld_is_dlopened.

However, if the following command is used for the build:

$ clang -pg -static test.c

the following binary is produced:

$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically
linked, for FreeBSD 12.2, FreeBSD-style, with debug_info, not stripped

(note the absence of "interpreter ..." part). This binary runs just fine:

$ lldb a.out
(lldb) target create "a.out"
Current executable set to '/usr/home/oleg/tmp/pg/a.out' (x86_64).
(lldb) run
Process 914 launching
Process 914 launched: '/usr/home/oleg/tmp/pg/a.out' (x86_64)
OK
Process 914 exited with status = 0 (0x00000000)
(lldb)

$ clang --version
FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-
10.0.1-0-gef32c611aa2)
Target: x86_64-unknown-freebsd12.2
Thread model: posix
InstalledDir: /usr/bin

[Quuxplusone]

Note also the discussion in https://bugs.freebsd.org/249121. A workaround was committed in FreeBSD in the mean time.

[Quuxplusone]

In particular Kostantin's comment 4:

> Clang+lld produce very strange binary when all linked libraries are static:
>
> Elf file type is EXEC (Executable file)
> Entry point 0x2237a0
> There are 11 program headers, starting at offset 64
>
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flg    Align
>   PHDR           0x0000000000000040 0x0000000000200040 0x0000000000200040
>                  0x0000000000000268 0x0000000000000268  R      0x8
>   INTERP         0x00000000000002a8 0x00000000002002a8 0x00000000002002a8
>                  0x0000000000000015 0x0000000000000015  R      0x1
>       [Requesting program interpreter: /libexec/ld-elf.so.1]
>   LOAD           0x0000000000000000 0x0000000000200000 0x0000000000200000
>                  0x000000000002279c 0x000000000002279c  R      0x1000
>   LOAD           0x00000000000227a0 0x00000000002237a0 0x00000000002237a0
>                  0x0000000000091760 0x0000000000091760  R E    0x1000
>   LOAD           0x00000000000b3f00 0x00000000002b5f00 0x00000000002b5f00
>                  0x0000000000001898 0x0000000000001898  RW     0x1000
>   LOAD           0x00000000000b57a0 0x00000000002b87a0 0x00000000002b87a0
>                  0x00000000000037c0 0x00000000002247a9  RW     0x1000
>   TLS            0x00000000000b3f00 0x00000000002b5f00 0x00000000002b5f00
>                  0x0000000000001850 0x0000000000001870  R      0x10
>   GNU_RELRO      0x00000000000b3f00 0x00000000002b5f00 0x00000000002b5f00
>                  0x0000000000001898 0x0000000000002100  R      0x1
>   GNU_EH_FRAME   0x000000000000fc80 0x000000000020fc80 0x000000000020fc80
>                  0x000000000000300c 0x000000000000300c  R      0x4
>   GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
>                  0x0000000000000000 0x0000000000000000  RW     0
>   NOTE           0x00000000000002c0 0x00000000002002c0 0x00000000002002c0
>                  0x0000000000000048 0x0000000000000048  R      0x4
>
> ...
>
> There is no dynamic section in this file.
>
> Relocation section with addend (.rela.dyn):
> r_offset     r_info       r_type              st_value         st_name +
r_addend
> 0000002bbf50 000000000025 R_X86_64_IRELATIVE  0000000000000000  + 223dd0
> 0000002bbf58 000000000025 R_X86_64_IRELATIVE  0000000000000000  + 2a91e0
>
> As you see, it specifies PHDR INTERP, which brings rtld into action.
> But there is no dynamic segment, so rtld cannot see any relocs, which results
> in the IRELATIVE relocation sites to still point to the resolver functions.
> This is arguably a bug in lld.

[Quuxplusone]

According to truss output, the -dynamic-linker flag is being explicitly passed
to lld:

  890: execve("/usr/bin/clang",[ "/usr/bin/clang", "-cc1", "-triple", "x86_64-unknown-freebsd12.2", "-emit-obj", "-mrelax-all", "-disable-free", "-disable-llvm-verifier", "-discard-value-names", "-main-file-name", "test.c", "-mrelocation-model", "static", "-mthread-model", "posix", "-mframe-pointer=all", "-fno-rounding-math", "-masm-verbose", "-mconstructor-aliases", "-munwind-tables", "-target-cpu", "x86-64", "-dwarf-column-info", "-fno-split-dwarf-inlining", "-debugger-tuning=gdb", "-resource-dir", "/usr/lib/clang/10.0.1", "-fdebug-compilation-dir", "/usr/home/oleg/tmp/pg", "-ferror-limit", "19", "-fmessage-length", "237", "-pg", "-fgnuc-version=4.2.1", "-fobjc-runtime=gnustep", "-fdiagnostics-show-option", "-fcolor-diagnostics", "-faddrsig", "-o", "/tmp/test-63e2c7.o", "-x", "c", "test.c" ],0x7fffffffebb0) EJUSTRETURN
  891: execve("/usr/bin/ld",[ "/usr/bin/ld", "--eh-frame-hdr", "-dynamic-linker", "/libexec/ld-elf.so.1", "--hash-style=both", "--enable-new-dtags", "-o", "a.out", "/usr/lib/gcrt1.o", "/usr/lib/crti.o", "/usr/lib/crtbegin.o", "-L/usr/lib", "/tmp/test-63e2c7.o", "-lgcc_p", "-lgcc_eh_p", "-lc_p", "-lgcc_p", "-lgcc_eh_p", "/usr/lib/crtend.o", "/usr/lib/crtn.o" ],0x7fffffffebb0) EJUSTRETURN

And, according to discussion here:

https://bugs.llvm.org/show_bug.cgi?id=47455

the addition of the interpreter with explicit -dynamic-linker flag is the
intended behavior, even if there will be no dynamic section in the resulting
binary. So I doubt that it's a bug in lld, lld just does what it's asked to do.
I think, the question is why -dynamic-linker flag is passed to lld in the first
place.