LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 34513 - Missing DW_OP_deref for non-trivial return by value
Summary: Missing DW_OP_deref for non-trivial return by value
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: DebugInfo (show other bugs)
Version: trunk
Hardware: PC Linux
: P enhancement
Assignee: Reid Kleckner
URL:
Keywords:
: 35654 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-09-06 16:28 PDT by David Blaikie
Modified: 2017-12-15 08:45 PST (History)
6 users (show)

See Also:
Fixed By Commit(s):

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Blaikie 2017-09-06 16:28:57 PDT 
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.
Comment 1 Adrian Prantl 2017-09-07 08:50:19 PDT 
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.
Comment 2 Adrian Prantl 2017-09-07 09:18:35 PDT 
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.

https://bugs.llvm.org/show_bug.cgi?id=32382
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.
Comment 3 Reid Kleckner 2017-09-07 09:35:31 PDT 
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.
Comment 4 Adrian Prantl 2017-09-07 09:39:54 PDT 
Yes, that would be in line with the commit message and the intention of the LLVM patch (r642022) that the message is referring to.
Comment 5 Reid Kleckner 2017-09-15 15:00:56 PDT 
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.
Comment 6 Adrian Prantl 2017-12-15 08:45:55 PST 
*** Bug 35654 has been marked as a duplicate of this bug. ***