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).
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.
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...