Closed Quuxplusone closed 5 years ago
Bugzilla Link | PR40283 |
Status | RESOLVED FIXED |
Importance | P normal |
Reported by | David Stenberg (david.stenberg@ericsson.com) |
Reported on | 2019-01-10 06:25:24 -0800 |
Last modified on | 2019-04-11 00:18:22 -0700 |
Version | trunk |
Hardware | PC Linux |
CC | david.stenberg@ericsson.com, jdevlieghere@apple.com, keith.walker@arm.com, llvm-bugs@lists.llvm.org, paul_robinson@playstation.sony.com |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
This seems to be due to the entry merging in DwarfDebug::buildLocationList()
not taking the preceding DBG_VALUE's range into account.
In fact, the DBG_VALUE for s.a does not have the end of its range calculated in
the history map, which can be seen by adding -debug:
DbgValueHistoryMap:
- s at <unknown location> --
Begin: DBG_VALUE $edi, $noreg, !"s", !DIExpression(DW_OP_LLVM_fragment, 0, 32), debug-location !45; foo.c:18:5 line no:18
Begin: DBG_VALUE $ebx, $noreg, !"s", !DIExpression(DW_OP_LLVM_fragment, 32, 32), debug-location !45; foo.c:18:5 line no:18
End : $rbx = frame-destroy POP64r implicit-def $rsp, implicit $rsp, debug-location !48; foo.c:20:3
This seems to be due to the calculator only dealing with one register per
inlined entity at a time, so it is not able to end the first range, since it
switches the register-of-interest from $edi to $ebx when encountering the
second DBG_VALUE. I guess that the calulator should be made fragment-aware and
be made to support multiple registers at a time?
Proposed patch: https://reviews.llvm.org/D59942
(In reply to David Stenberg from comment #2)
> Proposed patch: https://reviews.llvm.org/D59942
That has been merged as r358073 now. Closing this issue.