Greg Clayton wrote:
On Jun 30, 2014, at 10:50 PM, Matthew Gardiner <m...@csr.com> wrote:
Greg Clayton wrote:
As soon as we attach with any GDB server, we expect one of two things:
1 - a process and all its threads are stopped. the $? packet should respond
with any thread that has a stop reason _or_ if no threads have a stop reason,
then report a $T packet for the first thread. You can probably respond with
$T00 if there is no real signal or reason the thread stopped. Some debuggers
like to respond with $T05 (SIGTRAP), but I would rather we don't lie and report
a bogus SIGTRAP signal and tell the truth ($T00 or no signal).
2 - there is no process which means qProcessInfo respond with an invalid value
or error, or for backward compatibility qC responds with an invalid value. This
lets us know we don't have a process and no $? should be issued.
Hi Greg,
I appreciate this question may be slightly off-topic, but you mentioned that on attaching
to a GDB server you expect "a process and all it's threads are stopped" (or no
process).
Does the concept of a non-invasive attach exist in lldb? By that I mean can you
attach to a process without stopping it.
It does, just not with GDB remote. The GDB remote protocol has a very simple
design: send a packet then wait for a response and the protocol can do nothing
else unless interrupted (by sending a CTRL+C byte (0x03)).
So we would have to issue a command like "launch process" (the 'A' packet) and we get a response ("OK"). Now the process is
assumed to be stopped as far as I know since the only way to make the process run is to issue a continue packet ("c" or
"vCont:c") or a step packet ("s" or "vCont:s"). When we send these packets we wait for a response ("$TSS;..."
where SS is a hex signal number followed by key value pairs.
So there is no real feature in the protocol that allows for running without
first sending some form of a run packet (continue or step).
Yes, that's my conclusion, too.
We have this feature in our current debugger, in additional to permitting memory and
register reads for certain areas of our chips, it may useful to a developer to inspect
whether a device is "still running".
Yep, this can all be done by your custom lldb_process::Process subclass. With
the internal LLDB API, we have no problem saying a process is running
immediately after an attach, you would simply send a eStateLaunching event
followed by a eStateRunning event. We might have to tweak a few things in LLDB
to make sure this works, but it is possible.
I see what you mean. But then again I think I'm stuck on using
ProcessGDBRemote since that is the process subclass instantiated by lldb
on invoking "gdb-remote". (Especially in the bare-metal case, previously
discussed, where an ELF is not supplied, and thus lldb cannot glean the
kind of information required to know the process sub-class to create).
As such I'm not sure how far I can actually progress any such custom
process sub-class.
But if you create a target and then you set breakpoints:
(lldb) target create /bin/ls
(lldb) b malloc
(lldb) b free
Then you launch:
(lldb) process launch
Do you really want LLDB to try and set the "malloc" and "free" breakpoints
while your process is running? This will make you potentially miss the first N breakpoints hits if
your process doesn't start up stopped.
Right. In my world, with regard your breakpoint example, it is up to
"our users" (the people using our debuggers to develop embedded
systems), to determine the "safety" of placing breakpoints in running
targets. Typically they'd stop the target first, though. (We actually
have various architectures, and it is a hardware dependent thing if that
hardware support breakpoint modification whilst the chip is running).
I've also observed that the Microsoft Visual Studio debugger also permits
attach onto a running process, without it's interruption.
On most systems, even though attaching says it doesn't do anything, the process
often will briefly be stopped. I believe all unix variants will stop with a
SIGSTOP or SIGTRAP when you call ptrace() with the attach command.
In the UNIX world I totally agree with you (regarding attach
SIGSTOP/TRAP etc.) In my embedded experience, though, things can often
be very different. We connect to development boards over USB/SPI
interfaces and we can (hardware depending) read various "status"
registers regardless of the run-state and determine whether the device
is running, stopped, at break, PC value etc.
Is such a feature achievable using lldb via it's "target" or remoting commands?
We have also had requests for attaching to a running process, but the debugger
is going to want to stop right away and try and set breakpoints before
continuing to ensure the breakpoints can be hit.
So we can easily modify LLDB to do this kind of thing if this is important, but the GDB
remote protocol isn't a great target to make that work with. If we somehow taught the GDB
remote protocol to not return from the 'A' packet which launches a process, the only
thing we can do is interrupt the 'A' packet in order to send the "set
breakpoint" packet. So it would go like:
(lldb) process attach ...
send: send attach packet
wait for response which doesn't come back since we want /bin/ls to run
Now LLDB wants to send a breakpoint packet to set the breakpoints for "malloc" and
"free" but it can't since GDB remote can only send one packet at a time so we must
interrupt:
send: 0x03 (interrupt)
recv: stop reply packet from interrupt
send: set breakpoint at malloc packet
recv: reply for breakpoint packet
send: continue
send: 0x03 (interrupt)
recv: stop reply packet from interrupt
send: set breakpoint at free packet
recv: reply for breakpoint packet
send: continue
So now we have stopped the target multiple times because we wanted to send the
breakpoint packets while the target is running, instead of just once right
after we attach when the process is stopped.
So to sum up: yes this is possible with LLDB, but the ProcessGDBRemote is not a
great candidate for this change due to its design.
Greg
Yes, I agree ProcessGDBRemote is not a good place for this. It seems to
me that the gdb/UNIX tradition of always assuming a stopped target upon
attach is a tough one to buck. Since, for my users, the important
use-case is to inspect whether the target is "still running" (prior to
an optional invasive attach), I personally think that the platform
commands could provide me with a route forward....
I see we have:
(lldb) platform process info <pid>
Perhaps this command can be augmented to provide status information (in
a similar same way to how linux /proc/<pid>/status file works)? It's
then up to the user to attach and therefore intrude on the process. Do
you think such an approach is favourable?
thanks
Matt
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
www.youtube.com/user/CSRplc, Facebook,
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at
www.aptx.com.
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
