summaryrefslogtreecommitdiff
path: root/gdbsupport/environ.cc
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-02-08 13:56:22 +0000
committerAndrew Burgess <aburgess@redhat.com>2023-03-20 10:37:15 +0000
commit442716d400655e252f3faf93ae17ec410e73869d (patch)
treedfc0c9d317e6fc288bdfe4e5d24347fe06586e1c /gdbsupport/environ.cc
parent834e4d716226b4536bfeb4d20023c69c139eeb5a (diff)
downloadbinutils-gdb-442716d400655e252f3faf93ae17ec410e73869d.tar.gz
gdb: don't use the global thread-id in the saved breakpoints file
I noticed that breakpoint::print_recreate_thread was printing the global thread-id. This function is used to implement the 'save breakpoints' command, and should be writing out suitable CLI commands for recreating the current breakpoints. The CLI does not use global thread-ids, but instead uses the inferior specific thread-ids, e.g. "2.1". After some discussion on the mailing list it was suggested that the most consistent solution would be for the saved breakpoints file to always contain the inferior-qualified thread-id, so the file would include "thread 1.1" instead of just "thread 1", even when there is only a single inferior. So, this commit adds print_full_thread_id, which is just like the existing print_thread_id, only it always prints the inferior-qualified thread-id. I then update the existing print_thread_id to make use of this new function, and finally, I update breakpoint::print_recreate_thread to also use this new function. There's a multi-inferior test that confirms the saved breakpoints file correctly includes the fully-qualified thread-id, and I've also updated the single inferior test gdb.base/save-bp.exp to have it validate that the saved breakpoints file includes the inferior-qualified thread-id, even for this single inferior case.
Diffstat (limited to 'gdbsupport/environ.cc')
0 files changed, 0 insertions, 0 deletions