I have to say I quite like how this test turned out to look like. In terms of the last night's SBAPI vs. lldb-mi vs. whateever discussion, i'd can say that there is nothing preventing this test written in terms of the SB API. I didn't do it that way, because I have automatically written the test at the same level as the code I was modifying (which generally means the test is more light-weight and focused), but since the SBModule/SBSection don't have much additional logic themselves, it does not matter much in this case. However, I agree that we don't want to restrict ourselves to the SB API here -- SB is good at providing a debugger API, but with this tool we are explicitly not trying to test the debugger as a whole, but its individual pieces.
And as far as lldb-mi goes, writing a test for this through lldb-mi would quite challenging, as it is too high level. afaik (and I can't say that I know much about lldb-mi) there is no lldb-mi primitive that would let me read raw section data. And even if there was, I'd have to be very careful in constructing the test object file, so that it would look "valid enough" that lldb-mi would dare touch it. On 30 November 2017 at 14:02, Pavel Labath via Phabricator <revi...@reviews.llvm.org> wrote: > labath updated this revision to Diff 124926. > labath added a comment. > > This rewrites the test in terms on the new lldb-test utility. It should be > applied on top of https://reviews.llvm.org/D40636. > > While doing that, I noticed a discrepancy in the data presented by the object > file interface -- for GetFileSize(), it would return the compressed size, but, > when reading the data, it would return the decompressed size. This seemed odd > and unwanted. > > So now I fetch the decompressed size when constructing the Section object, and > make sure GetFileSize result matches what the GetSectionData returns. This is > slightly odd as well, because now if someone looks at individual section file > offsets and sizes, it will seem that multiple sections overlap. While > unfortunate, this is a situation that can arise in without the presence of > compressed sections (no linker will produce a file like that, but you can > certainly hand-craft one), and our elf parser will hapily accept these files. > > > https://reviews.llvm.org/D40616 > > Files: > lit/CMakeLists.txt > lit/Modules/compressed-sections.yaml > lit/Modules/lit.local.cfg > lit/lit.cfg > lit/lit.site.cfg.in > source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp > source/Plugins/ObjectFile/ELF/ObjectFileELF.h > tools/lldb-test/lldb-test.cpp > unittests/ObjectFile/ELF/TestObjectFileELF.cpp > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
