[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions

[Owen Shaw via Phabricator via lldb-commits]

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