[Lldb-commits] [PATCH] D155905: lldb RFC: Exposing set/get address masks, Fix*Address methods in SBProcess

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added inline comments.


================
Comment at: lldb/include/lldb/API/SBProcess.h:445
+  lldb::addr_t FixDataAddress(lldb::addr_t addr);
+  lldb::addr_t FixAnyAddress(lldb::addr_t addr);
+
----------------
clayborg wrote:
> What does this function do? Does it try to auto detect code/data low/hi on its own assuming that specific regions are easily identifiable?
We have the same method in Process.  Linux has separate masks for code & data addresses, so we have FixCode and FixData methods, but sometimes you just have an addr_t and you don't know the context (e.g. a register value that you're testing to see if it points to a symbol so you can print that as additional info to the user), and so in that case we have a Process::FixAddress.

There is one armv7 abi that clears the 0th bit on FixCode address, and I could see other ABIs doing similar things for the fixed nature of code addresses.  But Data addresses are the most general, having to point to any addressable byte.

Our Process/SBProcess say "FixCode if you know it's code, FixData if you know it's data.  And if you don't know, FixData".  But I think having a "FixAddress" method, making it clear that you don't know the origin of the value, makes the intention a little clearer.  Even if it's just calling FixData inside Process.


================
Comment at: lldb/source/API/SBProcess.cpp:1260-1261
+      return process_sp->GetHighmemDataAddressMask();
+    case eMaskTypeAny:
+      return process_sp->GetDataAddressMask();
+    }
----------------
clayborg wrote:
> Any reason we actually have a case for eMaskTypeAny? What makes this useful?
We have 4 different masks because of Linux's design, and because I have an internal customer doing different page table layouts for high & low memory in the same process (sigh), but realistically 99% of our programs are going to have the same mask for all 4 types.  Making an SB API user choose which mask they want of the four makes it harder to use, imo.  The folks doing genuinely unusual things, like the internal customer I have using high & low memory with different page table setups, can jump through the hoops of getting the different masks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155905/new/

https://reviews.llvm.org/D155905