-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should support multiple personality functions per module #1786
Comments
Partly implemented in: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070507/049541.html Now we're restricted only to one personality function per eh frame (=per |
A possible trick is to define our own personality function: this |
I don't think that will work, it breaks binary/ABI compatibility with GCC. |
Why? |
Because llvm-compiled C++/Ada files would produce references to symbols that don't exist in gcc |
The fake personality functions would be generated in each .s that |
ok, that leads to code bloat :) |
Yes, but since there would be most likely only one of Anyway, hopefully this kind of trick won't be needed at all. It's |
Also, by playing linkage tricks (eg: weak linkage) it may be possible |
I don't get it. What problem are you trying to solve? |
To be more specific: dwarf EH tables support multiple personality functions per executable, so we just |
Multiple personalities per function. I don't know if this is |
I have no idea what I'm talking about</> That said, it seems like it's just a matter of having the range table have entries for different personalities. |
So far as I can tell, LLVM does in fact support multiple personalities per module, so I'll mark it fixed as per the title. The rest of the bug comments discuss multiple personalities in one function. Supporting multiple personalities in a single function is IMO infeasible, as we'd need to split the function in the backend so that different regions of code have different EH tables. We'd also need some crazy CFI to make it work. Each object file format would present a unique set of challenges as well. |
mentioned in issue #1242 |
Extended Description
Current LLVM's EH design in some cases is neither consistent nor complete: in
one places it assumes only 1 personality function per module (and thus only one
common EH frame), but in other places it can theoretically support multiple
personality functions (recording them in the landing pads), but ... lacks callee
traversal code in order to assign them correct personality function.
For now I'm going to do "only one personality function per module". This will
allow to emit eh information at least without extra "hacks" and workaround.
Later (maybe for 2.1) we will probably do extra cfg traversal code in order to
assign correct personality function. However, this seems to be many problems
with indirect function calls....
The text was updated successfully, but these errors were encountered: