jasonmolenda wrote: I see the latest update includes the necessary changes to ThreadElfCore, that looks good.
I'm still curious what this code does when reading x0. The RegisterContext GPR struct defines 32 elements, pc + x1-x31, and the offset of x0 would be the 33rd element. But instead of using that GPR struct, this PR points into the corefile byte range where the GPRs are stored -- I'm assuming the elf file stores pc in the 0th position just like the RegisterContext does. Is the GPR register file in an rv32 corefile 32 elements long or 33? Are we reading past the end of the 32-element GPR registers when we read x0 and it happens to just be value 0, or maybe it's undefined and no one really read x0 so they don't notice? I still wonder about having `RegisterContextCorePOSIX_riscv32::ReadRegister` return UInt32(0) when x0 is requested. This code is largely the same as the rv64 corefile support which would have the same issue, if it is an issue, so I probably shouldn't worry so much. I suspect we can skate past an Address Sanitizer catching this even if we read one entry past the GPR range in the corefile because it's all mapped corefile data. https://github.com/llvm/llvm-project/pull/115408 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
