> On Apr 19, 2018, at 9:44 AM, Greg Clayton via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
> 
> 
> 
>> On Apr 19, 2018, at 6:51 AM, Zdenek Prikryl via lldb-dev 
>> <lldb-dev@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;
> };
> 

I'm curious why you are suggesting another kind of address, rather than adding 
this functionality to Address?  When you actually go to resolve an Address in a 
target with a process you should have everything you need to know to give it 
the proper space.  Then fixing the expression evaluator (and anything else that 
needs fixing) would be a matter of consistently using Address rather than 
lldb::addr_t.  That seems general goodness, since converting to an lldb::addr_t 
loses information.

Jim


> 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
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to