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.

Sign up for GitHub

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

Jump to bottom

invoke has no landing pad after codegen #1811

Closed
llvmbot opened this issue May 22, 2007 · 6 comments
Closed

invoke has no landing pad after codegen #1811

llvmbot opened this issue May 22, 2007 · 6 comments
Labels
bugzilla Issues migrated from bugzilla

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented May 22, 2007

Bugzilla Link 1439
Resolution FIXED
Resolved on Feb 22, 2010 12:47
Version unspecified
OS Linux
Attachments testcase .ll, original .cpp
Reporter LLVM Bugzilla Contributor
CC @asl

Extended Description

In the testcase there are two calls to @​__cxa_throw,
one of which is an invoke the other a normal call.
[Only the invoke one should be called when the program
is run].
After codegen
llc -enable-eh -asm-verbose e.bc
there is only one call to @​__cxa_throw but it
is the wrong one! First of all, from the assembler
comment (#finally) you can see that it is the normal
call version that got put in (the other is in finally.i):

.LBB2_1: #finally
movl $_ZTI1A, 4(%esp)
movl $_ZN1AD1Ev, 8(%esp)
movl %esi, (%esp)
call __cxa_throw
.LBB2_2: #unwind

Secondly, in the exception handling table there is no
landing pad for this code range, there is only

    .long   .Llabel4-.Leh_func_begin2       # Region start
    .long   .Llabel5-.Llabel4       # Region length
    .long   0x0     # Landing pad
    .uleb128        0       # Action

which does not cover this.

My guess is that codegen cleverly saw that it could collapse
the two calls to @​__cxa_throw into one call, thinking that they
were equivalent, without noticing that they differed in that
one was an invoke.
@llvmbot
Copy link
Collaborator Author

llvmbot commented May 22, 2007

Is this a new regression?

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 22, 2007

Is this a new regression?

I don't know.

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 23, 2007

Tail merging, mine.

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 23, 2007

Wrong again, this fails identically with tail merging turned off. Nor is it branch folding. I do not
understand how this works well enough to figure it out.

@asl
Copy link
Collaborator

asl commented May 23, 2007

Dale, this is EH issue.

The problem is:
1. Call is known to throw
2. But, it's outside any EH scope
we're not creating invoke in this case
this is right
inside f() it is; however the call to f() is an invoke
yes
I mean, inside f() it is outside any eh scope
doesn't this just indicate that stack unwinding is not working properly?
yes, in some sence:
if there won't be frame with personality function specified, it will
unwind upper by default
by when we have personality function, we should mark every call as "can
throw" and emit null LPs
(this is how gcc does)
so, this is some sort of "invalid EH information emitted" :)

@asl
Copy link
Collaborator

asl commented May 23, 2007

Fixed with:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070521/049953.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070521/049954.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070521/049955.html

@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
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@asl @llvmbot