jasonmolenda created this revision.
jasonmolenda added a reviewer: jingham.
jasonmolenda added a project: LLDB.
Herald added a subscriber: JDevlieghere.
Herald added a project: All.
jasonmolenda requested review of this revision.
Herald added a subscriber: lldb-commits.
If you add a binary to lldb
jasonmolenda added a comment.
I should have added, this bug has been in lldb probably forever - at least for
a few years.
Also, this test case explicitly builds without debug information because debug
information (on Darwin) results in a different bug being hit, where these data
symbols are no
DavidSpickett added a reviewer: DavidSpickett.
DavidSpickett 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 .
Is
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 t
jasonmolenda updated this revision to Diff 447821.
jasonmolenda added a comment.
Update test to address David's feedback, make it clearer how I picked the slide
values and also check that the load address of the symbols are updated properly
as the binary is slid.
Repository:
rG LLVM Github M
jasonmolenda added a comment.
One small comment on the updated test: surprisingly SBSymbol doesn't have a
GetSymbolSize(), probably because it's a computed value and it's possible that
we could not compute it, or the heuristic may be incorrect in a stripped
binary, so I get the start & end addr
DavidSpickett added inline comments.
Comment at:
lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py:57
+
self.assertNotEqual(second_sym.GetStartAddress().GetLoadAddress(target),
+ second_sym.GetStartAddress().GetFileAddress())
+
-
jasonmolenda updated this revision to Diff 462000.
jasonmolenda added a comment.
Getting back to this old patch. When I lost track of it, @DavidSpickett was
saying that the test case was still not clear -- I was loading a section at an
address, checking that I could read values out of arrays, t
jasonmolenda added a comment.
And to be clear, the problem is that we start out with an expression like
`first[0]` which we find the Section + address for `first`, then resolve to a
load address (addr_t) via the Target SectionLoadList, and then try to read
memory from that address - at which po
DavidSpickett accepted this revision.
DavidSpickett added a comment.
This revision is now accepted and ready to land.
Test is certainly clearer. LGTM.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D130534/new/
https://reviews.llvm.org/D130534
_
DavidSpickett added a comment.
FWIW the intent of the change was always clear but writing a test for it is
always going to be fiddly. My usual mindset is "what if this fails out of the
blue", so I'm always asking for more comments :) .
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG1fee25629d9d: Clear old section-to-addr entry when loading
Section at new addr (authored by jasonmolenda).
Repository:
rG LLVM Github Monorepo
CH
12 matches
Mail list logo