[PATCH] D137882: [DWARFLibrary] Add support to re-construct cu-index

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D137882#3961341 <https://reviews.llvm.org/D137882#3961341>, @ayermolo wrote:

> In D137882#3957811 <https://reviews.llvm.org/D137882#3957811>, @dblaikie wrote:
>
>> In D137882#3949594 <https://reviews.llvm.org/D137882#3949594>, @ayermolo wrote:
>>
>>> In D137882#3948380 <https://reviews.llvm.org/D137882#3948380>, @dblaikie wrote:
>>>
>>>> I think test coverage might be more suitable if it were a single dedicated test that has a corrupted index, to demonstrate that rebuilding the index comes up with a different (& correct) answer - rather than adding what looks sort of like redundant testing to existing test cases?
>>>
>>> I am not sure how to construct corrupted CU Index manually. Would Yaml2Obj be able to do it?
>>
>> I'm not sure - I don't think so. Might just have to be raw assembly - check the other symbolizer dwp testing? I think it's probably hand-crafted assembly? (maybe llvm-dwp testing that merges existing dwp files has some hand crafted dwp files too you could be inspired by)
>>
>> But maybe Yaml2Obj could help - I'm just not very familiar with this.
>>
>>> For other tests I think it's ads testing coverage to make sure we are parsing cu/tu indexes correctly in various DWARF versions and debug types enablements combinations.
>>
>> I'd rather keep things a bit narrower - demonstrate that the index is computed correctly, and assume that everything else works correctly once the index is correct.
>
> So...
> Good news is that I got inspired and created a hand written assembly with invalid index.
> Bad news is that this version of the patch relies on overflow behavior. See uint32_t TruncOffset.

UB when converting a uint64_t into a uint32_t? Hmm, I didn't think that was undefined - figured that'd wrap around with well defined behavior. Maybe I'm misunderstanding - what's the particular UB you're referring to?

> So just having one incorrect offset doesn't do anything.

Yeah, I'm still missing a step here. But I guess since we're only walking the offsets and looking for wraparound, this only has an effect if there's a genuine overflow, which would require a genuinely very large dwp file, which is infeasible to checkin as a test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137882