[PATCH] [mips] Make TTypeEncoding indirect to allow .eh_frame to be read-only.

Petar Jovanovic petar.jovanovic at imgtec.com
Tue May 19 10:26:38 PDT 2015


================
Comment at: lib/MC/MCObjectFileInfo.cpp:334
@@ +333,3 @@
+    TTypeEncoding = dwarf::DW_EH_PE_indirect | dwarf::DW_EH_PE_pcrel |
+                    dwarf::DW_EH_PE_sdata4;
+    // We don't support PC-relative LSDA references in GAS so we use the default
----------------
dsanders wrote:
> petarj wrote:
> > I see your comment for N64 ABI and DW_EH_PE_sdata8, but if it is complex to fix it in this change, and considering incompleteness of N32 and common use(rs) of LLVM today, would not we be closer to correct solution if this case is divided in two switch/cases for 32-bit and 64-bit triples, with dwarf::DW_EH_PE_sdata4 and DW_EH_PE_sdata8 flags set in TTypeEncoding respectively?
> It's not correct to use the triple to distinguish between ABI's. For example, it's valid to generate O32 code on a mips64-linux-gnu target. Admittedly, this currently doesn't work due to long standing misuse of triples in our backend which I'm slowly fixing.
> 
> Given that the TType is pc relative, we'd be fairly unlucky to need sdata8 in the near future.
> It's not correct to use the triple to distinguish between ABI's.

I was not saying that. I was implicating that common users of LLVM (such as Android) use common options such as mips64 with N64 ABI and mips32 with O32 ABI.

> For example, it's valid to generate O32 code on a mips64-linux-gnu target. Admittedly, this currently doesn't work due to long standing misuse of triples in our backend which I'm slowly fixing.

In LLVM as-is today, this will even trigger "Invalid  Arch & ABI pair." error. Check MipsSubtarget.cpp:92-94

> Given that the TType is pc relative, we'd be fairly unlucky to need sdata8 in the near future.

I am leaving this to you. The rest of the change looks fine, as far as I can see.

http://reviews.llvm.org/D9669

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list