LGTM from the FreeBSD side. The launch code for FreeBSD came from the original (in-process) implementation that Linux and FreeBSD shared.

I like this idea.

FreeBSD build and test in progress.

Fine from FreeBSD

In D34140#779285, @ruiu wrote:

This seems fine, but who actually passes "armelf"? Just want to confirm that this is in use.

This LGTM, I had hacked something like this locally for my FreeBSD/lld work.

Generally LGTM with two questions inline.

LGTM from my perspective.

Thanks! I will try to add an equivalent section for FreeBSD shortly after this goes in.

In D32271#759361, @dim wrote:

As I found out in rL303015, the KERN_PROC_PATHNAME has one drawback: if an executable file has multiple hard links, you will get just one of its filenames as the result. Since that filename is more or less randomly chosen, it does *not* have to correspond to the actual argv[0] the executable was invoked with. If that does not matter, this approach is fine, though.

Two small nits noted inline, but now the test does not pass without D32271 and does with it. Note that in the "without" case it returned error rather than failing, perhaps related to the path issue I noted?

Without tcmalloc, on Ubuntu 14.04, 40 core VM: 13%
With tcmalloc, on Ubuntu 14.04, 40 core VM: 24% (built using cmake ... -DCMAKE_EXE_LINKER_FLAGS=-ltcmalloc_minimal, which amazingly only works when building with clang, not gcc...)

Does it make sense to make it read-only from beginning?

The change looks fine to me from a FreeBSD perspective

This test passes even without the change in D32271, presumably because exe = os.path.join(os.getcwd(), 'newdir/proc_attach') is providing us with an absolute path for argv[0].

Test case in D32522

In D32271#735098, @krytarowski wrote:

I have plan to revisit corresponding files in NetBSD and switch from kvm(3) to sysctl(3). But this is lower priority than Process Plugin right now.

Slightly simpler approach after early returns added in rL301100

In D32120#734603, @krytarowski wrote:

I don't agree. It would mean that it's supposed to work on BSD4.4 and derivate systems like BSD/OS.

Sorry I've been away from LLDB for a bit, I will take a look at this soon.

In D32125#728166, @krytarowski wrote:

Is this just GNU specific? BSD moved to 64-bit off_t on 32-bit platforms 20+ years ago.

It's perhaps no-op, but it might be noted in the commit message what platforms are supposed to be improved.

As an aside we may want pthread_getthreadid_np() (the user-facing thread ID) on FreeBSD instead of pthread_self() (an opaque pointer), as a separate / later change.

For freebsd/Host.cpp I will also move Host::GetEnvironment near the end of the file (in the same place as linux/Host.cpp).

I compared the tmp objects in the failing and passing case using diffoscope and noticed one unexpected difference, although it does not appear to be root cause of the failure.

In D31528#716759, @atanasyan wrote:

Thanks a lot for your help. BTW what tools and libraries do you use to build LLD: Clang (what version?) or gcc, libc++ or libstdc++?

FreeBSD ostensibly supports o32, n32, and n64, so n32 is indeed relevant for us. That said the in-tree toolchain still uses GCC 4.2.1 for MIPS, and the LLVM work is still somewhat forward-looking for us.

One other note, I tried linking the FreeBSD base system on mips64 with this patch applied (since we require mxgot or multigot to be able to link the entirety of the base system), and have a reproducible segfault in lld. A reproducer is at https://people.freebsd.org/~emaste/lld/lld-mips.tar. It seems the crash is reproducible after reverting the patch, so I'll submit a bug for it shortly.

In D31528#715638, @atanasyan wrote:

Is the error reproduced each time? I just made a clean build with the patch and did not see the error.

I had ELF/mips-got-and-copy.s fail for me with this applied, with .../mips-got-and-copy.s.tmp.o:(.text+0xC): relocation R_MIPS_GOT16 out of range

FYI I added libexecinfo before FreeBSD 10 so all supported FreeBSD releases have it.

It was suggested on the libtool mailing list that --with-gnu-ld to configure scripts might override libtool's tool --version string check and forcibly enable the GNU ld code path. I haven't yet tried this and won't be able to for a few days, but will take a look next week if nobody else does first.

Although I'd rather not do this, I think it is a necessary workaround.

I'll follow up to my Jan 2017 libtool list posting about this issue with a link to this review. I hope that we can get some traction, such that this may be a short-term workaround rather than permanent descent into craziness like browser user agents.

We have the disassembly and offset anyway, so perhaps we should just drop the symbol name?

IMO if you want to link relocatable output, you should call the linker directly.

The FreeBSD components that prompted PR32118 link with this change.

A user has explicitly requested two different features that cannot be used together.

With this change, linking libcxxrt in FreeBSD succeeds.

extern "C++" { std::foo; } (as opposed to extern "C++" { "std::foo"; })

some unwinder implementations

Err, moved to D29667

Moved to D29666 to add lldb-commits with initial diff

In D29347#662503, @labath wrote:

@emaste: I'd suggest switching freebsd over to this process launcher as well. I think it's the last user of the ProcessLauncherPosix, and it would enable us to get rid of it.

My concern is that the stock gcc distributions for FreeBSD, NetBSD from your sources doesn't define __mips_abicalls,

In D29032#654854, @emaste wrote:

As mentioned in D29032

Err, that should be D29024

As mentioned in D29032 I agree with @joerg - __mips_abicalls should always be defined if this is what GCC does.

Sorting was committed in rL290494 and PT_LOAD in rL292170.

FYI the FreeBSD fix for this is here: https://svnweb.freebsd.org/changeset/base/303442

FreeBSD EFI loader build now fails with:

--- all_subdir_sys ---
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name copy.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name devicename.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name main.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name smbios.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name zfs.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name elf64_freebsd.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name trap.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name comconsole.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name boot.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name interp.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name interp_parse.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name module.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name load_elf32.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name load_elf64.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name disk.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name bcache.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name libefi.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name efipart.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name efinet.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: Section has different type from others with the same name efi_console.o:(.bss)
/tank/emaste/obj/tank/emaste/src/freebsd-xlld/tmp/usr/bin/ld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [loader.sym.full] Error code 1

Not part of this change, but it seems unfortunate that we use isGNUEnvironment or isOSLinux here to determine if sincos is available, but then in lib/Target/ARM/ARMSubtarget.cpp:

bool ARMSubtarget::hasSinCos() const {
  return isTargetWatchOS() ||
    (isTargetIOS() && !getTargetTriple().isOSVersionLT(7, 0));
}

and lib/Target/X86/X86ISelLowering.cpp:

bool X86Subtarget::hasSinCos() const {
  return getTargetTriple().isMacOSX() &&
    !getTargetTriple().isMacOSXVersionLT(10, 9) &&
    is64Bit();
}

I think this LGTM but I'm curious if !Index was just from a misunderstanding, or if @rafael encountered an object with e_shstrndx == 0?

Abandon in favour of D23934

Please also accept SOURCE_DATE_EPOCH set in the environment -- see https://reproducible-builds.org/specs/source-date-epoch/

In D28085#630631, @davide wrote:

For 2), please add a test and I'll take another look.

This seems reasonable to me.

this is the best I could find:

https://opensource.apple.com/source/libunwind/libunwind-35.3/src/UnwindLevel1-gcc-ext.c

In D27965#629005, @andrew.w.kaylor wrote:

It looks to me like you are probably correct about the intended mailing list post, but it's still not particularly helpful. It would be nice to have a reference to a primary source, but this is the best I could find:

https://opensource.apple.com/source/libunwind/libunwind-35.3/src/UnwindLevel1-gcc-ext.c

Our messages crossed paths. There are tests that use separate input files which are in the Inputs/ directory.

This needs a test case.

How do we handle combinations of related options?