[Lldb-commits] [PATCH] D130534: loading a binary at a slide multiple times leaves old entries in the SectionLoadList

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added inline comments.


================
Comment at: lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py:34
+
+        # View the first element of `first` and `second` with
+        # a load address .
----------------
DavidSpickett wrote:
> Is it worth checking here that the value of `&first` has actually changed, or is sliding in general tested elsewhere?
Good idea, that's not a bug we're seeing here (that's file address -> load address translation, if anything) but I mention that this test case doesn't work when there's debug info on Darwin; one way you can see the problem with debug info is that the address of these variables is not shown as changing, when the slide is applied.


================
Comment at: lldb/test/API/functionalities/multiple-slides/main.c:2
+int first[2048] = { 5 };
+int second[2048] = { 6 };
+int main()  {
----------------
DavidSpickett wrote:
> 2048 is a random number or are you fitting into some page size or just a distance big enough to prevent some accidentally correct but wrong behaviour by lldb?
The original bug report was disassembling functions, and it was easy to see that the load address -> file address calculation was incorrect.  For the test case I laid out the DATA and slides so I could repo this, but didn't show my work for how I got there.  If we have a file address for DATA of 0x104000, `first` is at fileaddr 0x104000 `second` is at fileaddr 0x00104800.  

We add a slide of 1990 (0x7c6), so now DATA is at load address 0x1047c6.  When I print `first`, that turns into a load address of 0x1047c6, translates to a DATA + 0 Address object, and when I print `second`, that turns into a load address of 0x00104fc6 which translates to DATA + 0x2048.

Then we slide to offset 4, so now DATA is at load address 0x104004.  But we still have the old 0x1047c6 load address in the table.  `first` is load address 0x104004 matches the entry for 0x104004, so it goes to DATA + 4.  `second` is load address 0x1047cc.  This matches the old 0x1047c6 entry in the addr->sect table, so it translates to DATA + 6, and now we're indexing into the middle of the `first` array.

I'll be honest, I didn't do the math on this when I made the test case, I just guessed at some numbers that would probably overlap in the right way, so it wasn't completely clear to me either, haha.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130534/new/

https://reviews.llvm.org/D130534