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

EH frames must be emitted in one "atom". #1752

Closed
asl opened this issue May 2, 2007 · 7 comments
Closed

EH frames must be emitted in one "atom". #1752

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

Comments

@asl
Copy link
Collaborator

asl commented May 2, 2007

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
Copy link
Collaborator

llvmbot commented May 2, 2007

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

@asl
Copy link
Collaborator Author

asl commented May 2, 2007

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
Copy link
Collaborator Author

asl commented May 2, 2007

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
Copy link
Collaborator

lattner commented May 3, 2007

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
Copy link
Collaborator Author

asl commented May 12, 2007

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

@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

3 participants