llvm-project

af3cc148 - [lldb][NFC] Add some override methods to VirtualDataExtractor (#179858)

[lldb][NFC] Add some override methods to VirtualDataExtractor (#179858) This changes VirtualDataExtractor's GetByteSize to return the virtual byte size of the buffer (external users only understand the data contents in terms of the virtual sizes & offsets). There are check methods in DataExtractor that check they are not going off the end of a buffer, they usually use the BytesLeft() method. There are a couple of callers of BytesLeft() externally, but it is predominantly an internal use API. I have BytesLeft() use the physical size of the buffer, not the virtual size, for the benefit of the DataExtractor methods. (and to avoid duplicating all of them down in VirtualDataExtractor) Another problem is the we call SetData on DataExtractorSP's (e.g. see the ObjectFile ctor) with the DataBuffer it already has, an offset of 0, and the GetByteSize. A no-op for a DataExtractor that is already using that DataBuffer. But SetData would try to use that length as a physical size, and truncate the buffer that the DataExtractor would accept. I added VirtualDataExtractor subclass methods for the SetData's, detect (1) data being added to an uninitialized DataExtractor, (2) the same data / offset / length as currently being used is added to the DataExtractor (a no-op), or (3) we're genuinely changing the data source or setting an offset / length that is different. This final case we're not ready to handle today, I added asserts for them so we can catch it in debug builds, and then I clear the LookupTable and add a no-op entry so this extractor will behave like a plain DataExtractor -- because I don't know better to do. If we genuinely need to handle this case, and I'm pretty sure we don't need to, I'd have to assume that we're taking a subset of the original data source (an offset & length), so we'd need to update all of the LookupTable entries to reflect the new offsets, and remove entries that are no longer referring to the subsetted range. I'll leave that until there's any evidence it's actually needed. rdar://148939795