Details

Makes sure that the unwind info uses 64bits pcrel relocation if a large code model is specified and handle the corresponding relocation in the ExecutionEngine. This can happen with certain kernel configuration (the same as the one in https://reviews.llvm.org/D27609, found at least on the ArchLinux stock kernel and the one used on https://www.packet.net/) using the builtin JIT memory manager.

Why is this ulittle64_t? I see a comment in D27609 about causing trouble on big-endian systems, but that doesn't explain why.

On aarch64 big-endian instructions are little-endian but data is big-endian. Relocations that are applied to instructions are always written little endian, but relocations that are written to data should be written in the target endianness. The R_AARCH64_PREL64 is only applied to data so I am not expecting to see ulittle64_t here.

I actually did not think about the support of aarch64_be in relocation (even though I added it to the FDE encoding condition....).

Ref https://reviews.llvm.org/rL284789
The reason for the ulittle*_t is to support running the JIT on big endian system (for tests and for remote JIT). This is also why the x86 relocations above also have the ulittle*_t in them even though there isn't any big endian x86 systems.

I'll check and use ubig*_t on the data part conditionally for aarch64_be in both PR if necessary.

I think the code changes and test look fine, but I think you should get this approved by one of the approvers of https://reviews.llvm.org/D6079, which is where the x86_64 large code model change was made along with the justification for it.

My last reservation is if this is the right thing to do on aarch64 (i.e. can both llvm and gnu libunwind handle DW_EH_PE_sdata8), and if so perhaps it should be applied for other 64-bit architectures with large code models that permit text segment sizes > 4Gb.

My is that the Jit makes it more likely that code and exceptions may be placed more than 32-bits apart when the large-code model is used, and that using the large-code model gives intent that larger exception tables will result.

I note that gcc still uses 32-bit sized entries even for AMD64, I'm guessing that this is because a Jit isn't involved and programs that span a > 4gb .text section size are rare or non-existent.

About IR vs assembler: the test is in principle completely target neutral. Makes it easier to copy for other archs and our testing here is certainly on the weak side.

About location: the test is for the MC infrastructure. It would be nice if it could just dump .eh_frame directly, but we still don't have tool support for that it seems. llc -asm-verbose also don't include anything about the FDE format. We might want to fix that though.