Consider the following program (test.c): $ 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)
This is a bug in lld. There was similar bug report recently, I cannot find its number.
I found similar bug report in LLVM bugtracker: https://bugs.llvm.org/show_bug.cgi?id=47455 with some discussion. According to truss output, the -dynamic-linker flag is actually being 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 However, it's unclear to me, why it is passed in the first place, if clang -pg wants to produce statically linked binary. There is apparently some inconsistency.