[PATCH] D14700: [mips][freebsd] Explicitly select PC-relative Personality and LSDA encodings.

[Daniel Sanders via llvm-commits]

> -----Original Message-----
> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> Sent: 19 November 2015 01:05
> To: Daniel Sanders
> Cc: reviews+D14700+public+694feb8b7227989b at reviews.llvm.org; llvm-
> commits; Sean Bruno
> Subject: Re: [PATCH] D14700: [mips][freebsd] Explicitly select PC-relative
> Personality and LSDA encodings.
> 
> > Not yet. The Linux toolchains reject it with 'Error: invalid or unsupported
> encoding in .cfi_personality' and similar. As things stand, we need GAS
> changes to fix this properly but once IAS is enabled by default* and stable
> we'll be able to ignore GAS's behaviour for most (hopefully all) toolchains.
> That said, we'll want to keep -fno-integrated-as working (at least for a while).
> 
> Do you know why? I just noticed that this is for 64 bit mips, so the
> function can be more than 32 bits away, no? Is that the reason gas
> rejects it?
> 
> Do they support it if you add DW_EH_PE_indirect or use sdata8?
> 
> Cheers,
> Rafael

This test case is 64-bit but 32-bit has the same problem.

I think the root of the problem is that there's no R_MIPS_PC64 relocation. There's a comment next to the '#define CFI_DIFF_EXPR_OK 0' that says it's there because there's no way to handle the N64 ABI. Unfortunately this macro also disables pcrel for O32/N32. The idea of adding R_MIPS_PC64 met opposition and I was told to look at composing R_MIPS_64 and R_MIPS_PC32 instead. I doubt this would work (because I expect the carry bit between bit 31 and 32 would be discarded) but I haven't had time to investigate it yet.

Using DW_EH_PE_indirect without DW_EH_PE_pcrel is accepted but lead to a link-time problem back when I was making read-only .eh_frame work for Android. It produced 'DT_TEXTREL in a shared library' warnings but I didn't establish the cause due to time constraints and the need to debug the linker to find the cause. I assume a particular conversion to pcrel is missing.
Using DW_EH_PE_pcrel and DW_EH_PE_sdata8 together doesn't work because of the lack of a relocation to handle it.

> so the function can be more than 32 bits away, no?

Potentially yes, but in practice it's very unlikely. You'd need code and data between the relevant .eh_frame and .data to exceed 4GB, or for the relevant .eh_frame and .data sections to be artificially loaded a long way from eachother.