summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
diff options
context:
space:
mode:
authorJason Molenda <jmolenda@apple.com>2015-12-18 00:45:35 +0000
committerJason Molenda <jmolenda@apple.com>2015-12-18 00:45:35 +0000
commit545304d323d6bbebdddcd93a7b657e761b8df168 (patch)
treef17f00e522076977eb48896d516600eae1ad3b51 /lldb/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
parent545b8861fc40bb194d6e8daa382f9d6d4659a13b (diff)
downloadbcm5719-llvm-545304d323d6bbebdddcd93a7b657e761b8df168.tar.gz
bcm5719-llvm-545304d323d6bbebdddcd93a7b657e761b8df168.zip
The lldb side changes to go along with r255711 where a new
"thread-pcs" key is added to the T (questionmark) packet in gdb-remote protocol so that lldb doesn't need to query the pc values of every thread before it resumes a process. The only odd part with this is that I'm sending the pc values in big endian order, so we need to know the endianness of the remote process before we can use them. All other register values in gdb-remote protocol are sent in native-endian format so this requirement doesn't exist. This addition is a performance enhancement -- lldb will fall back to querying the pc of each thread individually if it needs to -- so when we don't have the byte order for the process yet, we don't use these values. Practically speaking, the only way I've been able to elicit this condition is for the first T packet when we attach to a process. <rdar://problem/21963031> llvm-svn: 255942
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud