lldb-server process crashes when debugging on pcc64le #54520
Comments
|
@llvm/issue-subscribers-lldb |
|
PPC64 in lldb is not very well maintained. I don't have the hardware to try it out, but I suppose it's possible that some (newer) ppc64 machines have 16 watchpoints, and that we didn't anticipate that. Are you able to recompile lldb and change the array size to 16? It would be interesting to see if that fixes the crash, and whether you are actually able to set all 16 watchpoints. If you have gdb around, you could also try setting 16 watchpoints there. |
|
Making |
|
@llvm/issue-subscribers-backend-powerpc |
|
@labath Any opinion on just increasing the array size? Or should I investigate why we're trying to access 16 watchpoints in the first place? I can provide patches as well. |
|
If watchpoints don't work (you could check with gdb whether they are /supposed to/ work on your machine), then I don't think increasing the array size is very helpful -- I'd be tempted to just yank out the ppc watchpoint support code completely. Unless, of course, you want to investigate and fix watchpoint support -- that would definitely be better, but I have no idea how much work would that be. |
|
I looked into this again, and I think there are a few things worth noting: The problematic case is the one where the user does not try to make use of hardware watchpoints. In this case ReadHardwareDebugInfo() never gets called and m_max_hwp_supported stays at the default value of 16. When GetWatchpointHitIndex() later gets called (I believe around the time the process exits?) we're still using that default and read outside the bounds of the array. On the hardware I'm testing (which is likely the same that @tbaederr used) no hardware watchpoints are actually available, or at least that's what num_data_bps in the ptrace PPC_PTRACE_GETHWDBGINFO call reports. So I think just making the array size and m_max_hwp_supported consistent is all that needs to be done here. Worth noting that the ARM implementation of watchpoints is pretty much exactly the same as on ppc64le, the only notable difference is that they don't have this size mismatch... I guess the only question is whether the array size should increase to 16 or the default m_max_hwp_supported decrease. I'm not familiar with the hardware capabilities here, but increasing the array size should be the safer option (in case there is hardware with many watchpoints). |
|
Put up https://reviews.llvm.org/D136144 with this change. |
The size of the m_hwp_regs array should match the default value of m_max_hwp_supported. This ensures that no out-of-bounds accesses occur, even if the array is accessed prior to a call to ReadHardwareDebugInfo(). Fixes llvm#54520, see also there for additional background. Differential Revision: https://reviews.llvm.org/D136144
Backtrace:
NativeRegisterContextLinux_ppc64le::m_hwp_regsis astd::arrayof size 4, but them_max_hwp_supportedvariable is initialized to 16. Is this intentional?I understand that
m_max_hwp_supportedcan later be assigned a different value viaReadHardwareDebugInfo(), but that has either not happened or yields 16 anyway.The text was updated successfully, but these errors were encountered: