Unfortunately, the TAPI releases are in the wild, so we need to support the old files. It would be nice to have some sort of marker on the file (similar to a shebang) to indicate that it is a TAPI file.

I'd actually like to echo @ruiu's comment here. I don't think that ELF has much to gain from the textual representation (unlike MachO). ELF doesn't have the fat binary support, so you cannot really collapse multiple slices into a single slice and only mark differences in the slices from a common base. Furthermore, by exploiting the fact that ELF is extremely flexible in terms of what it considers a valid object, we can actually limit a stub to just the symbol table and the ELF header I believe. This is going to be a few extra bytes for the fields in the ELF header that we don't care about (e.g. magic). Since the majority of the binary will be the string table, I expect it to compress pretty well and be roughly in the same area as a textual representation. One added benefit of such an approach is that it is retroactively compatible with existing linkers. They should accept the output even though the binary would not be usable to run!

Yeah, this seems right. The builtins currently have some dependencies on libm, so you won't be able to build with -z defs.

LGTM. WRT the test case, is the DI needed? If not, I would strip the debug info for the test.

I'm not sure I understand this patch. Building libc++abi with libsupc++ doesn't make sense. They are both providing the same API. Are you trying to build against libgcc? The GNU Savannah libunwind as well as the LLVM libunwind provide the definitions AFAICT. libgcc has the definition in unwind-common.h.

SVN r344202

This seems reasonable to me. @whitequark, are you okay with them too? To @whitequark's original point, I think that the dispatching the type based on a query is pretty cool (you can do an enumeration + union output), but, I think API-wise, this is safer and easier to work with, not to mention also simplifies the implementation.

Wow, thanks for fixing this. I believe that @peter.smith is right and that the behaviour is something new.

SVN r342929 (with tests)

This seems reasonable to me, however, I would want to give @scanon a few (work) days to see if he has any comments on the actual implementation of logb.

This looks fine to me, but this definitely should have an accompanying test.

LGTM, thanks!

It definitely shouldn't be PUBLIC, PRIVATE makes sense for this inclusion. Is there a library that pulls in the dependency (that is, do the other libraries need it due to lldbHost? If so, just adding it as INTERFACE on that library should be sufficient).

Can you use target_include_directories instead and do this only on lldbHost instead please? That restricts the inclusion to just that target, which would help prevent accidental inclusion of the headers. That is the change should be to source/Host/CMakeLists.txt.

Sure, I think I can live with this.

@t.p.northover - okay, in that case, we can leave it here. I suppose that this is caused by the pair-wise split relocations à la IMAGE_REL_ARM_MOV32T for PE/COFF?

@peter.smith, yeah, I think that sharing this might make it more complex. This looks fine to me, any other concerns?

Can you move the LOH handling into the DarwinAsmParser rather than adding the MachO specific check here please?

Ah, I see. I think I had overlooked the .incbin.

Seems fine with the adjusted comment

The install- target is created by add_llvm_install_targets, not by the component. The component is part of CMake itself, and is controlled by the CMAKE_INSTALL_DEFAULT_COMPONENT_NAME.