We should revisit the implicit dependency on fdio. For other compiler-rt libraries' Fuchsia ports, we've kept it at the pure vDSO and minimal libc ABIs.

lgtm

lgtm

lgtm but I'm not authoritative.

lgtm

Lgtm

Lgtm with some more comments

When targetting Darwin we should really not be even compiling libc++/libc++abi and certainly should not have anything else compiling against their headers since at runtime the system libraries will be used and so things better compile against the system headers that match.
Do these settings accomplish that?

We aren't actually using DWARF 5 yet AFAICT. Our builds don't pass -gdwarf-5. So I'm not sure we have yet verified that all the DWARF-consuming tools people are using with Fuchsia binaries can handle all of DWARF 5 (which has several major format changes). I'd certainly like 5 to be the default, but I think we need to establish a set of consumers we care about and verify their format version support before we can be sure about this.

So Sam and I had dinner together. :-) I don't know a lot about WebAssembly and Sam doesn't know a lot about traditional (e.g. ELF) linkers, so we talked about the parallels in somewhat general terms while explaining the specifics to each other without distracting from our dessert.
In talking about what WebAssembly wants to do with converting some kinds of references to other kinds, I described the obvious analogy to the various kinds of linker relaxation that have been done in traditional machine code linking such as ELF.
There are two precedents that I can cite in detail off hand. In both cases the reloc type is specified in the ABI as for use with certain instruction patterns and the linker is expected to rewrite instructions with complete knowledge of their meaning, rather than just deliver values into bitfields.
One is x86-64's GOTPCREL and GOTPCRELX relocs, where GNU linkers check for expected opcode bytes immediate prior to the r_offset location and silently forego the instruction-rewriting optimization if the reloc is not used in the expected context.
The other is x86-64's TLS relocs, where GNU linkers check the opcode bytes immediatley prior to the r_offset location and diagnose an error if they don't match specific instruction patterns prescribed in the ABI for each reloc that enables linker relaxation (IIRC for some cases the x86 ABI mandates that linkers perform the relaxation, rather than just describing how the optimization is possible).
I don't know off hand how LLD handles these cases, but I would say that matching the GNU linkers' behavior is right--with the possible caveat that perhaps there should be a warning emitting for using GOTPCRELX relocs with instructions the linker doesn't know how to rewrite.
I know that other machines have many more relocs that are prescribed in their ABIs as for use with specific instruction patterns, but I don't know off hand what the details of those are, nor how existing linkers handle situations where such relocs are used with mismatching instructions.

lgtm

lgtm

I wonder if cpplint.py is worthwhile any more. Perhaps it should be replaced by a check that clang-format doesn't decide to change anything.

clang-format and lib/sanitizer_common/scripts/cpplint.py disagree about whitespace before braces.

ping. Will this or D41277 land?

This works fine for me. Perhaps Rui should land D39348 first and then you can rebase this in terms of that to discuss the remaining features (-R alias, no input files case).

Mutual exclusion is not target-specific and is already handled in SanitizerArgs. The test coverage for that looks fine.

Works for me. D41277 works just as well. I don't know how you plan to reconcile the two.

Great! Please land it for me.

This change as is fixes my real-world case.
Thanks! Now I'm just blocked on --just-symbols...

Fuchsia bit LGTM. Linux bit highly suspect.

lgtm

LGTM

LGTM

test case?

LGTM with comment added but if a different approach will be required for multiple Linux targets (which we all treat as "hostish") then it's worth at least thinking about that now.

LGTM. I wonder if it's really worth keeping --strip-non-alloc.

In principle this should be OK since we're unconditionally building the runtimes for default.
However, this means that any dynamically-linked host builds will assume our toolchain-provided shared libraries are available on the runtime host in standard library places.
I don't think we want that. Perhaps we could make -static-libstdc++ default in our host targets. But that's not really enough, since compiler-rt has some too. Probably better to just disable building the shared libraries altogether for the host targets.

This doesn't implement the -R switch name, which is the traditional interface from time immemorial. I can use --just-symbols, but you really should handle -R too.

lgtm

lgtm

This seems like how it always should have been, since -fuse-ld=lld sets it to ld.lld, not lld.
Looks to me like the existing MipsLinux and WebAssembly implementations are wrong too and only BareMetal is right.

This change works on my case, but it names the reloc sections it emits based on the first input section in the output section being relocated rather than on the output section itself.
e.g. in my -ffunction-sections --gc-sections --emit-relocs build, the SHT_RELA section with sh_info pointing to the .text section is called .rela.text.first_function_in_text rather than .rela.text.

LGTM
Since we use lld, -Wl,-O2 also helps make the binaries smaller.

http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section describes alignment of the contents of notes. Maintaining that alignment is obviously impossible if the section is not so aligned.

LGTM

I wonder why my builds have never had an undefined symbol HandleDeadlySignal.

What effect does this have?
Nothing built for Fuchsia ought to be using sanitizer_signal_interceptors.inc or HandleDeadlySignal in the first place.

Mostly LGTM

LGTM

Not being expert in the yaml2obj code base, this looks good to me with the caveats below.

I'm not closely familiar with this code base, so it should probably still get some review from someone who has reviewed the objcopy implementation so far.
But just looking at the apparent logic in this change, it looks OK to me with the caveats noted below.

Re-land of https://reviews.llvm.org/D36599
Actually builds now that compiler-rt has been updated.

LGTM

In D36811#843915, @vitalybuka wrote:

As now it's going to be apart of API, please add a test

Added test case.

You have a bunch of changes here to support individual members >=4G, but I'm not sure there is any need for that.
The bug is just about the whole archive being >=4G so that the member offsets need to be 64 bits.
If you want to support members >=4G I think that can be a separate change since it's not related to the bug.

This is necessary for D36599 to (re-)land.

LGTM

Rebased and ready to land once D36385 has landed.
Please land it for me!

I think I've done everything requested in review.
If you are both happy with it now, please land it for me!

Options struct for Init.
Remove excess reformatting.
Don't change tctx->detached.

Rebased

Updated stale comment. Changed FinishThread logic as suggested in review.

Thanks! Please land it for me.

Rebased

Avoided new argument to FinishThread.

Split out D36385. Reduced number of #if's. Moved Fuchsia-specific implementations into asan_fuchsia.cc.