-
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
EH frames must be emitted in one "atom". #1752
Comments
Perhaps we need a sorted appending linkage type? The only question is, on what |
eh table consists of entries. Each entry describes misc. bits of function frame. Another solution: the section inspection code has "trapdoor" case, when it |
Addendum: such "unsorted" trapdoor can lead to significant slowdown at the |
LLVM should be able to do whatever GCC does. These tables are generated by the codegen, so they don't |
One more reason for this stuff: Currently we're emitting common EH frame after first function. And we have to Having everything (common EH frame plus function frames) emitted in one atom in I'm just inserting workaround to get C++ personality routine for now, if there |
mentioned in issue #1242 |
Extended Description
Currently there are two ways of registering eh function frames during runtime:
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.
The text was updated successfully, but these errors were encountered: