Skip to content
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

Closed
asl opened this issue May 12, 2007 · 15 comments
Closed

Should support multiple personality functions per module #1786

asl opened this issue May 12, 2007 · 15 comments
Labels
bugzilla Issues migrated from bugzilla llvm:codegen

Comments

@asl
Copy link
Collaborator

asl commented May 12, 2007

Bugzilla Link 1414
Resolution FIXED
Resolved on Jan 14, 2015 16:28
Version trunk
OS Linux
Blocks #1242
CC @rnk

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

@asl
Copy link
Collaborator Author

asl commented May 13, 2007

Partly implemented in:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070507/049541.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070507/049542.html

Now we're restricted only to one personality function per eh frame (=per
function). This is much better. Also, these patches allows us not to do CFG
traversal (whoo!).

@llvmbot
Copy link
Collaborator

llvmbot commented May 14, 2007

A possible trick is to define our own personality function: this
would do some extra reasoning to identify the correct real
personality function, then dispatch to that one. For example it
could just call each real personality function in turn until it
finds one that handles the exception. It could also do something
more clever based on the ip.

@lattner
Copy link
Collaborator

lattner commented May 14, 2007

I don't think that will work, it breaks binary/ABI compatibility with GCC.

@llvmbot
Copy link
Collaborator

llvmbot commented May 14, 2007

I don't think that will work, it breaks binary/ABI compatibility with GCC.

Why?

@lattner
Copy link
Collaborator

lattner commented May 15, 2007

Because llvm-compiled C++/Ada files would produce references to symbols that don't exist in gcc
compiled libstdc++.

@llvmbot
Copy link
Collaborator

llvmbot commented May 15, 2007

Because llvm-compiled C++/Ada files would produce references to symbols that
don't exist in gcc compiled libstdc++.

The fake personality functions would be generated in each .s that
needs them.

@lattner
Copy link
Collaborator

lattner commented May 15, 2007

ok, that leads to code bloat :)

@llvmbot
Copy link
Collaborator

llvmbot commented May 15, 2007

ok, that leads to code bloat :)

Yes, but since there would be most likely only one of
these per module that's not so bad. Also, even if there
was one per function, that's still not so bad compared to
the size of the eh tables themselves. All this fake personality
function has to do is: call real_personality_1; return if result=found;
call real_personality_2; return if result=found; That's not a huge
amount of code. The minimum size of a eh table seems to be 16 bytes.

Anyway, hopefully this kind of trick won't be needed at all. It's
a last resort if we can't get the desired effect more directly.

@llvmbot
Copy link
Collaborator

llvmbot commented May 15, 2007

Also, by playing linkage tricks (eg: weak linkage) it may be possible
to get down to one copy per executable, even if we output one copy per
.s.

@lattner
Copy link
Collaborator

lattner commented May 15, 2007

I don't get it. What problem are you trying to solve?

@lattner
Copy link
Collaborator

lattner commented May 15, 2007

To be more specific: dwarf EH tables support multiple personality functions per executable, so we just
need to emit the right tables if there are multiple personality functions in a module.

@llvmbot
Copy link
Collaborator

llvmbot commented May 15, 2007

dwarf EH tables support multiple personality functions per executable

Multiple personalities per function. I don't know if this is
supported, so just threw out this fake personality idea in case
it isn't supported. It seems to have grown a life of its own :)

@lattner
Copy link
Collaborator

lattner commented May 15, 2007

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.
There are two issues: 1) book keeping at the llvm level, so you know the personality of each call, and 2)
emitting the tables correctly in the code generator.

@rnk
Copy link
Collaborator

rnk commented Jan 15, 2015

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.

@lattner
Copy link
Collaborator

lattner commented Nov 27, 2021

mentioned in issue #1242

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla llvm:codegen
Projects
None yet
Development

No branches or pull requests

4 participants