LLVM EH and PIC

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

LLVM EH and PIC

David Chisnall-2
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

--
This email complies with ISO 3103


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM EH and PIC

Anton Korobeynikov
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

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM EH and PIC

David Chisnall-2
On 25 Jan 2010, at 10:04, Anton Korobeynikov wrote:

> 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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] LLVM EH and PIC

Anton Korobeynikov
> 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.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM EH and PIC

Bill Wendling
In reply to this post by David Chisnall-2
On Jan 24, 2010, at 10:40 AM, David Chisnall wrote:

> 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-.
>
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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM EH and PIC

Anton Korobeynikov
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

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM EH and PIC

David Chisnall-2
In reply to this post by Bill Wendling
On 12 Mar 2010, at 20:53, Bill Wendling wrote:

> 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.


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

David

-- Send from my Jacquard Loom


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev