jasonmolenda added a comment. I have to agree with David, I don't see how the old code could overflow if DW_OP_deref_size's maximum size is the pointer size in the target, and we are reading it in to an 8-byte buffer, unless the target had addresses larger than 8 bytes, or the dwarf was malformed. The DWARF5 doc says
"In the DW_OP_deref_size operation, however, the size in bytes of the data retrieved from the dereferenced address is specified by the single operand. This operand is a 1-byte unsigned integral constant whose value may not be larger than the size of the generic type. The data retrieved is zero extended to the size of an address on the target machine before being pushed onto the expression stack" If there was an invalid dwarf input file that had a DW_OP_deref_size with a size of 16, we will only read the first 8 bytes of it into our buffer, and then try to extract 16 bytes with a call to `DerefSizeExtractDataHelper`, which will only read an Address sized object out of the buffer so it won't exceed the length. I think this change may be hiding a real bug in the DWARF @cmtice ? Do you have a record of what the input file that caused the address sanitizer to trip was? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D153840/new/ https://reviews.llvm.org/D153840 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
