[all-commits] [llvm/llvm-project] 6e6d5e: [lldb] Don't invalid register context after settin...

[Jason Molenda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6e6d5eae765939cc4074bdd606658e78c4a2a559
      https://github.com/llvm/llvm-project/commit/6e6d5eae765939cc4074bdd606658e78c4a2a559
  Author: Jason Molenda <jmolenda at apple.com>
  Date:   2024-09-23 (Mon, 23 Sep 2024)

  Changed paths:
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
    A lldb/test/API/macosx/expedited-thread-pcs/Makefile
    A lldb/test/API/macosx/expedited-thread-pcs/TestExpeditedThreadPCs.py
    A lldb/test/API/macosx/expedited-thread-pcs/foo.c
    A lldb/test/API/macosx/expedited-thread-pcs/main.cpp

  Log Message:
  -----------
  [lldb] Don't invalid register context after setting thread pc's (#109499)

Some gdb remote serial protocol stubs will send the thread IDs and PCs
for all threads in a process in the stop-reply packet. lldb often needs
to know the pc values for all threads while at a private stop, and that
results in <n-1> read-register packets for <n> threads, and can be a big
performance problem when this is a hot code path.

GDBRemoteRegisterContext tracks the StopID of when its values were set,
and when the thread's StopID has incremented, it marks all values it has
as Invalid, and knows to refetch them.

We have a code path that resulted in setting the PCs for all the
threads, and then `ProcessGDBRemote::CalculateThreadStopInfo` *forcing*
an invalidation of all the register contexts, forcing us to re-read the
pc values for all threads except the one that stopped.

There are times when it is valid to force an invalidation of the
regsiter cache - for instance, if the layout of the registers has
changed because the processor state is different, or we've sent a
write-all-registers packet to the inferior and we want to make sure we
stay in sync with the inferior. But there was no reason for this method
to be forcing the register context to be invalid.

I added a test when running on Darwin systems, where debugserver always
sends the thread IDs and PCs, which turns on packet logging. The test
runs against an inferior which has 4 threads; it steps over a dlopen()
call, steps in to a user function with debug info, steps-over and
steps-in across source lines with multiple function calls, and then
examines the packet log and flags it as an error if lldb asked for the
pc value of any thread at any point in the debug session.

For this program and the operations we're doing, with debugserver that
provides thread IDs and PCs, we should never ask for the value of a pc
register.

rdar://136247381



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications