EH frames must be emitted in one "atom".

[asl]

Bugzilla Link	1380
Resolution	FIXED
Resolved on	Feb 22, 2010 12:56
Version	trunk
OS	Linux
Blocks	#1242

Extended Description

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.

[llvmbot]

Perhaps we need a sorted appending linkage type? The only question is, on what
key is the thing sorted?

[asl]

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.

[asl]

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

[lattner]

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.

[asl]

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

[asl]

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

[lattner]

mentioned in issue #1242