aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/python.h
diff options
context:
space:
mode:
authorPedro Alves <pedro@palves.net>2023-11-17 12:41:36 +0000
committerPedro Alves <pedro@palves.net>2023-12-20 21:20:15 +0000
commit7d1fd6713582f2436a9a569ac7a8700c75e35a42 (patch)
tree9777752451f8ccf02dea9a603093f7502084c728 /gdb/python/python.h
parent45fd40cf54292caad19baef666e6b3318350a9fe (diff)
downloadgdb-7d1fd6713582f2436a9a569ac7a8700c75e35a42.zip
gdb-7d1fd6713582f2436a9a569ac7a8700c75e35a42.tar.gz
gdb-7d1fd6713582f2436a9a569ac7a8700c75e35a42.tar.bz2
Fix thread target ID of exited waves
Currently, if you step over kernel exit, you see: stepi [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited] Command aborted, thread exited. (gdb) Those '?' are because the thread/wave is already gone by the time GDB prints the "exited" notification, we can't ask dbgapi for any info about the wave anymore. This commit fixes it by caching the wave's coordinates as soon as GDB sees the wave for the first time, and making amd_dbgapi_target::pid_to_str use the cached info. At first I thought of clearing the wave_info object from a thread_exited observer. However, that is too soon, resulting in this: (gdb) si [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited] Command aborted, thread exited. (gdb) thread [Current thread is 6 (AMDGPU Wave ?:?:?:0 (?,?,?)/?) (exited)] We need instead to clear the wave info when the thread is ultimately deleted, so we get: (gdb) si [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited] Command aborted, thread exited. (gdb) thread [Current thread is 6 (AMDGPU Wave 1:4:1:1 (0,0,0)/0) (exited)] And for that, we need a new thread_deleted observable. Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu) Change-Id: I6c3e22541f051e1205f75eb657b04dc15e547580
Diffstat (limited to 'gdb/python/python.h')
0 files changed, 0 insertions, 0 deletions