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

[Pavel Labath via Phabricator via llvm-commits]

labath added a comment.

Ok, so this is what seems to be happening:
The vdso "file" has the following program headers:

  Program Headers:
    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
    LOAD           0x000000 0xffffe000 0x00000000 0x00434 0x00434 R E 0x1000
    DYNAMIC        0x000324 0xffffe324 0x00000324 0x00090 0x00090 R   0x4
    NOTE           0x0001c4 0xffffe1c4 0x000001c4 0x00034 0x00034 R   0x4
    GNU_EH_FRAME   0x0001f8 0xffffe1f8 0x000001f8 0x00024 0x00024 R   0x4

Your patch makes the makes us use the physical addresses (because some of the physical addresses are non-null), but in this case that is incorrect. For this file the VirtAddr describes the correct address of the file/section/segment in memory. Also the addresses in the section headers  (which is what we were using previously are correct.

Going back to your patch, it's not clear to me whether using physical addresses as load addresses is a correct thing to do in general. I mean, generally, we care about the places where the object file is located in virtual memory, and in physical, so maybe we should keep use virtual addresses here, and have ObjectFile::LoadInMemory use physical addresses through some other api? What do you think?

That said, on my desktop machine I get the following program headers from the vdso:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x00d1a 0x00d1a R E 0x1000
  DYNAMIC        0x0002bc 0x000002bc 0x000002bc 0x00090 0x00090 R   0x4
  NOTE           0x000560 0x00000560 0x00000560 0x00060 0x00060 R   0x4
  GNU_EH_FRAME   0x0005c0 0x000005c0 0x000005c0 0x00024 0x00024 R   0x4

and things still work fine, so it may be possible to make this work by just changing how we compute the load bias (I have to look up where we do that). 
(However, I am still not sure about using physical addresses being the right thing here).


Repository:
  rL LLVM

https://reviews.llvm.org/D42145