[lldb-dev] Advice on architectures with multiple address spaces

[Greg Clayton via lldb-dev]

> On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Hi lldb developers,
> 
> I've been researching using lldb + gdbserver stub that is based on Harvard architecture with multiple address spaces (one program, multiple data). The commonly adopted approach is that everything is mapped to a single "virtual" address space. The stub reads/writes from/to the right memory based on the "virtual" addresses. But I'd like to use real addresses with address space id instead. So, I've started looking at what has to be changed.
> 
> I've enhanced read/write commands (e.g. memory read --as <id> ...) and RSP protocol (new packet) so that the stub can read/write properly. That wasn't that complicated.

It might be nice to add a new RSP protocol packet that asks for the address space names/values:

qGetAddressSpaces

which would return something like:

1:text;2:data1,3:data2

or it would return not supported. If we get a valid return value from qGetAddressSpaces, then it enables the use of the new packet you added above. Else it defaults to using the old memory read functions.


> 
> Now I've hit an issue with expressions (LLVMUserExpression.cpp) and local variables (DWARFExpressions.cpp). There is a lot of memory read/write functions that take just an address argument. Is the only way to go to patch all these calls? Has anybody solved it differently?

My quick take is that any APIs that take just a lldb::addr_t would need to take something like:

struct SpaceAddress {
  static constexpr uint32_t kNoSpace = 0;
  lldb::addr_t addr;
  uint32_t space;
};

We would need a default value for "space" (feel free to rename) that indicates the default address space as most of our architectures would not need this support. If we added a constructor like:

SpaceAddress(lldb::addr_t a) : addr(a), space(kNoSpace) {}

Then all usages of the APIs that used to take just a "lldb::addr_t" would implicitly call this constructor and continue to act as needed. Then we would need to allow lldb_private::Address objects to resolve to a SpaceAddress:

  SpaceAddress lldb_private::Address::GetSpaceAddress(Target *target) const;

Since each lldb_private::Address has a section and each section knows its address space. Then the tricky part is finding all locations in the expression parser and converting those to track and use SpaceAddress. We would probably need to modify the allocate memory packets in the RSP protocol to be able to allocate memory in any address space as well.

I didn't spend much time think about correct names above, so feel free to suggest alternate naming. 

Best advice:
- make things "just work" to keep changes to a minimum and allowing lldb::addr_t to implicitly convert to a SpaceAddress easily
- when modifying RSP, make sure to check for existence of new feature before enabling it
- query for address space names so when we dump SpaceAddress we can show something that means something to the user. This means we would need to query the address space names from the current lldb_private::Process for display.

Submitting might go easier if we break it down into chunks:
1 - add SpaceAddress and modify all needed APIs to use it
2 - add ProcessGDBRemote changes that enable this support

It will be great to support this as a first class citizen within LLDB. You might ask the Hexagon folks if they have done anything in case they already support this is some shape or form.

Greg Clayton