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....
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!).
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.
I don't think that will work, it breaks binary/ABI compatibility with GCC.
> 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 compiled libstdc++.
> 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.
ok, that leads to code bloat :)
> 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.
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.
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 need to emit the right tables if there are multiple personality functions in a module.
> 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 :)
<disclaimer>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.
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.