Currently there are two ways of registering eh function frames during runtime: 1. __register_frame_info call (and friends) in the early beginning (crtbegin.o). 2. Direct eh section inspection ("GLIBC" method). Unfortunately, it seems the __register_frame_info call not always emitted (e.g. crtbegin.o compiled during llvm-gcc compilation without LLVM itself lacks this call). The second approach uses some assumptions. One of the biggest assumption is that entries in eh frame section are sorted according to PC's stored in entries. We can easily achieve this, if we emit information at once in the end (like gcc does). When we're emitting this information in separate "parts" (but in one section, of course), linker can permute "parts" making sort assumption invalid. This is needed for backward compatibility of generated eh information.
Perhaps we need a sorted appending linkage type? The only question is, on what key is the thing sorted?
eh table consists of entries. Each entry describes misc. bits of function frame. Among that information there is also "coverage area", e.g. function start address and function length (roughly, actually the "exception covering space"). The entries should be sorted by function start address. This address is set by linker. Another solution: the section inspection code has "trapdoor" case, when it thinks, that information is not sorted and do sort by itself. For LLVM-generated information is thinks that information *is* sorted. Probably, we need to find the way to drop to "unsorted" case.
Addendum: such "unsorted" trapdoor can lead to significant slowdown at the application initialization, if there are much eh information (because runtime needs to sort the things).
LLVM should be able to do whatever GCC does. These tables are generated by the codegen, so they don't need appending linkage or anything like that.
One more reason for this stuff: Currently we're emitting common EH frame after first function. And we have to put personality function there. This is possible only if there is some eh-related stuff in the first function, which is usually false. Having everything (common EH frame plus function frames) emitted in one atom in the end will resolve this problem, because we'll definitely see personality function, if any. I'm just inserting workaround to get C++ personality routine for now, if there is no personality function available (sorry, Duncan!).
Fixed in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070507/049536.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070507/049537.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070507/049538.html