[all-commits] [llvm/llvm-project] 2ba1ae: [lldb] Don't use a vm addr range starting at 0 for...

[Jason Molenda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2ba1aeed2efd8156717886f89f6d4270b1df7a18
      https://github.com/llvm/llvm-project/commit/2ba1aeed2efd8156717886f89f6d4270b1df7a18
  Author: Jason Molenda <jmolenda at apple.com>
  Date:   2024-07-24 (Wed, 24 Jul 2024)

  Changed paths:
    M lldb/docs/resources/lldbgdbremote.md
    M lldb/source/Expression/IRMemoryMap.cpp

  Log Message:
  -----------
  [lldb] Don't use a vm addr range starting at 0 for local memory (#100288)

When an inferior stub cannot allocate memory for lldb, and lldb needs to
store the result of expressions, it will do it in lldb's own memory
range ("host memory"). But it needs to find a virtual address range that
is not used in the inferior process. It tries to use the
qMemoryRegionInfo gdb remote serial protocol packet to find a range that
is inaccessible, starting at address 0 and moving up the size of each
region.

If the first region found at address 0 is inaccessible, lldb will use
the address range starting at 0 to mean "read lldb's host memory, not
the process memory", and programs that crash with a null dereference
will have poor behavior.

This patch skips consideration of a memory region that starts at address
0.

I also clarified the documentation of qMemoryRegionInfo to make it clear
that the stub is required to provide permissions for a memory range that
is accessable, it is not an optional key in this response. This issue
was originally found by a stub that did not list permissions in its
response, and lldb treated the first region returned as the one it would
use. (the stub also didn't support the memory-allocate packet)



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications