Changed contribution data structure to 64 bit. I added the 32bit and 64bit
accessors to make it explicit where we use 32bit and where we use 64bit. Also to
make sure sure we catch all the cases where this data structure is used.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
Perhaps the change to use accessors could be removed, now that you've used it to find all the places that needed to be fixed up? (like just using it for cleanup/temporary purposes, without needing to commit that API change?)
llvm/include/llvm/DebugInfo/DWARF/DWARFUnitIndex.h | ||
---|---|---|
115 | How come this became an array? Rather than keeping it as two named fields? |
I am not sure what other projects are using it, that I missed, or not in llvm-trunk, but are based of it.
llvm/include/llvm/DebugInfo/DWARF/DWARFUnitIndex.h | ||
---|---|---|
115 | So I can provide a generic set interface to be used in llvm-dwp and on bolt side. Maybe there is another way of doing it in c++? I also didn't want to make it overly complicated. // Write the offsets. writeIndexTable(Out, ContributionOffsets, IndexEntries, DWARFUnitIndex::Entry::SectionContribution::OffsetFieldIndex); // Write the lengths. writeIndexTable(Out, ContributionOffsets, IndexEntries, DWARFUnitIndex::Entry::SectionContribution::LengthFieldIndex); void writeIndexTable(MCStreamer &Out, ArrayRef<unsigned> ContributionOffsets, const MapVector<uint64_t, UnitIndexEntry> &IndexEntries, unsigned Index) { for (const auto &E : IndexEntries) for (size_t I = 0; I != std::size(E.second.Contributions); ++I) if (ContributionOffsets[I]) Out.emitIntValue((E.second.Contributions[I].getField32(Index)), 4); } |
It's awkward to convolute the API to ensure a breakage - I think it's best to leave it as-is, for the most part. I guess you needed the 32 bit accessors so existing code doesn't become UB because of truncation to 32 bit?
Could the code keep the existing member names, provide the wrappers without turning the members into an array and needing named index constants, etc, at least? (though even then, seems like there's more to it than needed)
Thanks for circling back to this during holidays. :)
Right, that was my original thought pattern. I am fully open to the idea that this is not the right approach. :)
@dblaikie If getter/setter APIs are a blocker, I can remove them and do casts (uint32_t) instead....?
I don't know that there's enough out of tree usage to worry about forcing a break by changing the API like this - or to include the "get*32" functions.
Is this actually an undefined behavior issue (I don't think the implicit conversion would be any more broken than the explicit cast, at least - but can't find the specific wording about defined/undefined behavior off hand at the moment) , or only an attempt to identify places that could benefit from updates to support 64 bit lengths?
Eh, still seems weird, but guess it's not that much of a big deal - so let's go with it.
@ayermolo This has broken some buildbots - please can you take a look? https://lab.llvm.org/buildbot/#/builders/245/builds/3279
https://reviews.llvm.org/D141504
TBH not 100% sure on the fix, but looking where it's failing, maybe it's some kind of interaction with APIs returning 64bit number, and 32bit format macros on ARM?
I don't have access to ARM machine.
Trying a fix for arm.
Couldn't repro locally with colleague on mac with ARM. So reverted will resubmit with potential fix to test on build bot.
How come this became an array? Rather than keeping it as two named fields?