LLVM EH and PIC

Hi all,

At the moment, clang is generating code that crashes in the unwind library if you use the GNU runtime and use -fPIC. The problem is that the relevant entry in the type table looks like this:

  .long .L.str

Where .L.str is defined elsewhere as:

.L.str:
    .asciz "Object"

This is fine in non-PIC code, but when the EH personality function loads this value after relocation has taken place, it gets the offset within the module, rather than the real address, dereferences a random bit of memory, and crashes.

I think this is an LLVM bug, and it should be generating PIC-aware code for pointers passed to llvm_eh_selector(), but possibly I am doing something wrong in clang. Are you meant to do anything magic to make the pointers that you pass to llvm_eh_selector() PIC-aware? The code works if I modify the generated assembly and changing that line to:

  .long .L.str-.

David

Hi, David

I think this is an LLVM bug, and it should be generating PIC-aware code for pointers passed to llvm_eh_selector(), but possibly I am doing something wrong in clang. Are you meant to do anything magic to make the pointers that you pass to llvm_eh_selector() PIC-aware? The code works if I modify the generated assembly and changing that line to:

This is PR5004

Is there any work around that I can use? GNUstep Make passes -fPIC by default, so this causes any GNUstep code containing @catch blocks with any type other than id to crash when compiled with clang.

Note that this happens for me on IA32 as well as x86-64 - everything in the bug report seems to be x86-64 specific.

David

-- Sent from my Cray X1

Is there any work around that I can use?

Not yet. I'm slowly working on the problem - hopefully it will be
completed in next few weeks.

I don't know if any one has answered this yet...

It looks like you may have a conflict between absolute pointers and indirect pointers in PIC mode. Do you have a .bc file that shows the problem? It's quite possibly an LLVM problem, because that's the code that determines what the encoding of pointers in the LSDA etc. are.

-bw

Hi, Bill

It looks like you may have a conflict between absolute pointers and indirect pointers in PIC mode. Do you have a .bc file that shows the problem? It's quite possibly an LLVM problem, because that's the code that determines what the encoding of pointers in the LSDA etc. are.

iirc, David confirmed that fix from PR5004 fixed the problem for him

This was PR5004. Anton fixed it a few weeks ago and now unwinding works nicely on not-Darwin.

David

-- Send from my Jacquard Loom