Details
Diff Detail
Event Timeline
lldb/source/Utility/DataExtractor.cpp | ||
---|---|---|
884 | Ummm.. why don't you just pass m_end here? The last argument is the end of the buffer, not the end of the number... |
lldb/source/Utility/DataExtractor.cpp | ||
---|---|---|
884 | From what I can see decodeSLEB128 doesn't have any detection logic for ints > 64bits, so it would just keep reading data until it finds something that looks like the terminating byte (or the end of the buffer) in case of malformed input. But if we explicitly limit the buffer to 10 bytes then it will stop and set a reasonable error message (even though we don't use that yet in LLDB). I did the same for decodeULEB128 just for the sake of symmetry (as that function curiously figures out this error case on its own). I'm fine with just passing m_end here though (that would make this patch more NFC as we currently also don't handle malformed input). |
lldb/source/Utility/DataExtractor.cpp | ||
---|---|---|
884 | If we're going to be using that function, I think we ought to rely on it to determine what constitutes a malformed LEB128. Also, the current version has a bug in that it does not check whether src + max_int64_size is still inside the data extractor range. |
lldb/source/Utility/DataExtractor.cpp | ||
---|---|---|
884 | Yeah, I think you're right. Updated the patch, thanks! |
Looks good
lldb/source/Utility/DataExtractor.cpp | ||
---|---|---|
911 | Should we hoist this into llvm as well (as a separate patch). It seems like at least lld/ELF/EhFrame.cpp is using the same functionality. |
lldb/source/Utility/DataExtractor.cpp | ||
---|---|---|
911 | TBH, I'm tempted to just delete it. I doubt that "skipping" an LEB128 is going to be noticeably faster than "reading" it, and llvm::DataExtractor has no equivalent function... |
lldb/source/Utility/DataExtractor.cpp | ||
---|---|---|
911 | Even better :-) |
Ummm.. why don't you just pass m_end here? The last argument is the end of the buffer, not the end of the number...