[lldb-dev] qHostInfo proposal to add breakpoint pc offset
ted.woodward at codeaurora.org
Fri Jun 6 06:56:44 PDT 2014
Yes - we have 2 GDB servers. One is in a simulator, and uses "hardware"
breakpoints. These give us the PC correctly. The other is a stub running on
hardware that uses software breakpoints, and gives us PC+4. We could change
it, but we're using GDB to talk to it right now, and GDB expects PC+4.
From: Greg Clayton [mailto:gclayton at apple.com]
Sent: Thursday, June 05, 2014 7:02 PM
To: Ted Woodward
Cc: lldb-dev at cs.uiuc.edu
Subject: Re: [lldb-dev] qHostInfo proposal to add breakpoint pc offset
It is always better if the GDB server can do the backing up of the PC and we
generally want this to happen. We don't always know how breakpoints are set
when we use the Z packets to set/clear breakpoints. If there are hardware
resources, then a breakpoint might get set as a hardware breakpoint and not
require the backing up of the PC. Again, these are all details that the GDB
server should be in charge of. If you hit a breakpoint that was set by the
user, then the PC should be backed up. If you hit a hard coded breakpoint
trap that was compiled in to the code, then you don't backup the PC.
I believe this support was added for one GDB server that didn't do the
backing up, but I would rather not have every GDB server have to tell us
that. Do you have one such GDB server that doesn't backup the PC when it
> On Jun 5, 2014, at 1:49 PM, Ted Woodward <ted.woodward at codeaurora.org>
> On some architectures, when a breakpoint is hit, the PC is set to a
different value and needs to be adjusted. This is handled in
ProcesGDBRemote.cpp by the variable m_breakpoint_pc_offset. The problem is
this variable is only set via a python target definition file.
> I propose extending qHostInfo to add bp_pc_decr:<offset>.
m_breakpoint_pc_offset would be set to this signed integer.
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
More information about the lldb-dev