[llvm-bugs] [Bug 38857] [codeview] Incorrect variable locations with stack realignment and call-frame optimization

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Oct 26 16:44:56 PDT 2018


https://bugs.llvm.org/show_bug.cgi?id=38857

Bruce Dawson <brucedawson at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #12 from Bruce Dawson <brucedawson at chromium.org> ---
So, it turns out this isn't quite fixed. I created a test branch for this bug
and for 38847. It creates and aliases a local variable called
"remaining_bytes_again" with a very distinctive value, and then intentionally
crashes in memcpy. The stack walk now works perfectly (so 38847 is fixed,
thanks!), but the displaying of locals is still wrong.

The artificial local variable is initialized like this:

uint64_t remaining_bytes_again = (remaining_bytes_ & 0x100000) + 0x12345678AB;

But windbg displays its value like this:

0:015> dt remaining_bytes_again
Local var @ 0xc16f544 Type unsigned int64
0x002e4151`00000012

The 0x12 is supposed to be in the high DWORD but instead it is in the low
DWORD. Looking at the stack I can see the full 8-byte value, but offset by four
bytes.

I've uploaded my test branch to crrev.com/c/1303399. My gn args are:

is_component_build = false
is_debug = false
target_cpu = "x86"
enable_nacl = false
use_goma = true
symbol_level = 2
remove_webcore_debug_symbols = true

All I do is launch chrome.exe under the debugger and wait. I usually log in to
gmail but I am not sure that is needed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181026/b5dbfe96/attachment-0001.html>


More information about the llvm-bugs mailing list