[lldb] Fix ARM32 inferior calls

echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()'

Actual:

  error: Expression can't be run, because there is no JIT compiled function

Expected:

  <nothing, sync() has been executed>

This patch has been checked by:
  D71707: clang-tidy: new bugprone-pointer-cast-widening
  https://reviews.llvm.org/D71707

Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended:

  echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long
long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out
  <stdin>: In function ‘main’:
  <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000

With debug output:
Actual:

  IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3)
  Code can be run in the target.
  Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff
  Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv
  Sections:
  [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text)
  ...
  HandleCommand, command did not succeed
  error: Expression can't be run, because there is no JIT compiled function

Expected:

  IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3)
  IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060].
  Code can be run in the target.
  Found function, has local address 0xb6fac000 and remote address 0xb6ff9020
  Function's code range is [0xb6ff9020+0x40]
  ...
  Function data has contents:
  0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1
  ...
  Function disassembly:
  0xb6ff9020: 0xe92d4c10   push   {r4, r10, r11, lr}

Differential revision: https://reviews.llvm.org/D71498
This commit is contained in:
Jan Kratochvil
2019-12-21 11:12:17 +01:00
parent 4af6866708
commit df6879ec02
6 changed files with 15 additions and 15 deletions

View File

@@ -328,9 +328,9 @@ lldb::addr_t IRMemoryMap::Malloc(size_t size, uint8_t alignment,
case eAllocationPolicyMirror:
process_sp = m_process_wp.lock();
LLDB_LOGF(log,
"IRMemoryMap::%s process_sp=0x%" PRIx64
"IRMemoryMap::%s process_sp=0x%" PRIxPTR
", process_sp->CanJIT()=%s, process_sp->IsAlive()=%s",
__FUNCTION__, (lldb::addr_t)process_sp.get(),
__FUNCTION__, reinterpret_cast<uintptr_t>(process_sp.get()),
process_sp && process_sp->CanJIT() ? "true" : "false",
process_sp && process_sp->IsAlive() ? "true" : "false");
if (process_sp && process_sp->CanJIT() && process_sp->IsAlive()) {
@@ -577,9 +577,9 @@ void IRMemoryMap::WriteMemory(lldb::addr_t process_address,
if (lldb_private::Log *log =
lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS)) {
LLDB_LOGF(log,
"IRMemoryMap::WriteMemory (0x%" PRIx64 ", 0x%" PRIx64
"IRMemoryMap::WriteMemory (0x%" PRIx64 ", 0x%" PRIxPTR
", 0x%" PRId64 ") went to [0x%" PRIx64 "..0x%" PRIx64 ")",
(uint64_t)process_address, (uint64_t)bytes, (uint64_t)size,
(uint64_t)process_address, reinterpret_cast<uintptr_t>(bytes), (uint64_t)size,
(uint64_t)allocation.m_process_start,
(uint64_t)allocation.m_process_start +
(uint64_t)allocation.m_size);
@@ -708,9 +708,9 @@ void IRMemoryMap::ReadMemory(uint8_t *bytes, lldb::addr_t process_address,
if (lldb_private::Log *log =
lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS)) {
LLDB_LOGF(log,
"IRMemoryMap::ReadMemory (0x%" PRIx64 ", 0x%" PRIx64
"IRMemoryMap::ReadMemory (0x%" PRIx64 ", 0x%" PRIxPTR
", 0x%" PRId64 ") came from [0x%" PRIx64 "..0x%" PRIx64 ")",
(uint64_t)process_address, (uint64_t)bytes, (uint64_t)size,
(uint64_t)process_address, reinterpret_cast<uintptr_t>(bytes), (uint64_t)size,
(uint64_t)allocation.m_process_start,
(uint64_t)allocation.m_process_start +
(uint64_t)allocation.m_size);