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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
