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

Missing DW_OP_deref for non-trivial return by value #33861

Closed
dwblaikie opened this issue Sep 6, 2017 · 8 comments
Closed

Missing DW_OP_deref for non-trivial return by value #33861

dwblaikie opened this issue Sep 6, 2017 · 8 comments
Assignees
@rnk
Labels
bugzilla Issues migrated from bugzilla debuginfo

Comments

@dwblaikie
Copy link
Collaborator

Bugzilla Link 34513
Resolution FIXED
Resolved on Dec 15, 2017 08:45
Version trunk
OS Linux
CC @adrian-prantl,@pogo59,@rnk

Extended Description

Try this in a debugger:

struct string {
string() {}
string(int i) : i(i) {}
~string() {}
int i = 0;
};
string get_string() {
string unused;
string result = 3;
return result;
}
int main() { get_string(); }

$ clang++ -g -fno-exceptions str.cpp

$ gdb ./a.out
b 10
r
p result
p (string)result

Looks like there's a missing DW_OP_deref in here somehow.
@dwblaikie
Copy link
Collaborator Author

assigned to @rnk

@adrian-prantl
Copy link
Collaborator

Hmm.. I couldn't reproduce this my system compiler (apple-clang-802) and lldb
and behold, the location also uses a DW_OP_deref
AT_location( 0x00000000
0x0000000100000e88 - 0x0000000100000ebb: rbp-24, deref )

so perhaps this is a recent regression?

With
clang version 6.0.0 (trunk 310529) (llvm/trunk 310534)

I get

0x00000055: TAG_variable [4]
AT_location( 0x00000000
0x0000000100000e88 - 0x0000000100000ebb: rbp-24 )

and can reproduce the bug in lldb.

I'll bisect now.

@adrian-prantl
Copy link
Collaborator

Looks like I broke this myself :-(

[clang] Debug Info: Remove special-casing of indirect function argument handling.

LLVM has changed the semantics of dbg.declare for describing function
arguments. After this patch a dbg.declare always takes the address
of a variable as the first argument, even if the argument is not an
alloca.

#31729
rdar://problem/31205000

git-original-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300523

Once I have a fix, I will add a variant of this test to the debuginfo-tests to avoid regressing again.

@rnk
Copy link
Collaborator

rnk commented Sep 7, 2017

IMO the fix for this will live in LLVM, I've fixed this bug several times now while iterating on https://reviews.llvm.org/D37311. My current patch uses DW_OP_LLVM_memory, but I'm not happy with it.

@adrian-prantl
Copy link
Collaborator

Yes, that would be in line with the commit message and the intention of the LLVM patch (r642022) that the message is referring to.

@rnk
Copy link
Collaborator

rnk commented Sep 15, 2017

After r313400 and r313399 this should work both in -O0 and in many cases when optimized. I added a debuginfo-tests test in r313401, so hopefully this doesn't regress.

@adrian-prantl
Copy link
Collaborator

*** Bug llvm/llvm-bugzilla-archive#35654 has been marked as a duplicate of this bug. ***

@adrian-prantl
Copy link
Collaborator

mentioned in issue llvm/llvm-bugzilla-archive#35654

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rnk rnk

Labels
bugzilla Issues migrated from bugzilla debuginfo
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rnk @adrian-prantl @dwblaikie