summaryrefslogtreecommitdiffstats
path: root/llvm/lib/MC/MCObjectFileInfo.cpp
diff options
context:
space:
mode:
authorPetr Hosek <phosek@chromium.org>2019-07-22 18:52:42 +0000
committerPetr Hosek <phosek@chromium.org>2019-07-22 18:52:42 +0000
commitf6cd6ffbc9f8bfa0bbe25dba6a9737607a684bab (patch)
tree1dba4a914b3bbcb71e7b91a1c000cd5cb84b1d97 /llvm/lib/MC/MCObjectFileInfo.cpp
parentef5cfc2dae0725226254561b42134308720e57ab (diff)
downloadbcm5719-llvm-f6cd6ffbc9f8bfa0bbe25dba6a9737607a684bab.tar.gz
bcm5719-llvm-f6cd6ffbc9f8bfa0bbe25dba6a9737607a684bab.zip
[SafeStack] Insert the deref after the offset
While debugging code that uses SafeStack, we've noticed that LLVM produces an invalid DWARF. Concretely, in the following example: int main(int argc, char* argv[]) { std::string value = ""; printf("%s\n", value.c_str()); return 0; } DWARF would describe the value variable as being located at: DW_OP_breg14 R14+0, DW_OP_deref, DW_OP_constu 0x20, DW_OP_minus The assembly to get this variable is: leaq -32(%r14), %rbx The order of operations in the DWARF symbols is incorrect in this case. Specifically, the deref is incorrect; this appears to be incorrectly re-inserted in repalceOneDbgValueForAlloca. With this change which inserts the deref after the offset instead of before it, LLVM produces correct DWARF: DW_OP_breg14 R14-32 Differential Revision: https://reviews.llvm.org/D64971 llvm-svn: 366726
Diffstat (limited to 'llvm/lib/MC/MCObjectFileInfo.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud