[lldb-dev] strange behaviour at lldb cmd line

[Matthew Gardiner]

Greg Clayton wrote:
>> On Jun 30, 2014, at 10:50 PM, Matthew Gardiner <mg11 at 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.