labath added a comment.

In https://reviews.llvm.org/D42145#1022717, @owenpshaw wrote:

> > 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.


Ok, so it seems to me that we do want the rest of the debugger to operate on 
virtual addresses, as that's what you will be debugging (except when you are 
actually debugging the boot code itself, but we can't be correct all the time.

> 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.

Since there is just one caller of this function maybe we don't even need to 
that fancy. Could the LoadInMemory function do the shifting itself?
I'm thinking of something like where it takes the load bias as the argument and 
then adds that to the physical address it obtains from the object file. 
Thinking about that, I'm not even sure the function should be operating at the 
section level. If it's going to be simulating a loader, shouldn't it be based 
on program headers and segments completely (and not just use them for obtaining 
the physical address)?


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