owenpshaw added a comment.

> And I'm not even completely clear about your case. I understand you write the 
> module to the physical address, but what happens when you actually go around 
> to debugging it? Is it still there or does it get copied/mapped/whatever to 
> the virtual address?

In  my case it's a hardware target with ROM and RAM.  Only the data section has 
different virtual and physical addresses.  That data section should be loaded 
to its physical address in ROM so it'll be preserved across resets.  The first 
code to execute on boot copies the data section from ROM to its virtual address 
in RAM.

> So it seems to me the physical addresses should really be specific to the 
> "target modules load --load" case. I've never used that command so I don't 
> know if it can just use physical addresses unconditionally, or whether we 
> need an extra option for that "target modules load --load --physical". I 
> think I'll leave that decision up to you (or anyone else who has an opinion 
> on this). But for the other use cases, I believe we should keep using virtual 
> addresses.

The "target modules load --load" case was originally intended to accomplish 
what gdb's "load" command does (see https://reviews.llvm.org/D28804).  I know 
gdb uses the physical address when writes the sections.

> So I think we should revert this and then split out the loading part of this 
> patch from the vFlash thingy so we can focus on the virtual/physical address 
> situation and how to handle that.

It's like we need the original all-virtual SectionLoadList in 
ObjectFileELF::SetLoadAddress, but a different SectionLoadList for the 
ObjectFile::LoadInMemory case, a function which is only used by "target modules 
load --load".

Or instead instead of a second list, maybe SectionLoadList gets a second pair 
of addr<->section maps that contain physical addresses.  Then 
ObjectFile::LoadInMemory can ask for the physical instead of virtual.


Repository:
  rL LLVM

https://reviews.llvm.org/D42145



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

Reply via email to