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