Re: embedded system and "target remote"

[Matthias Pfaller <leo@marco.de>]

[-- Attachment #1: Type: text/plain, Size: 4059 bytes --]

On 11/08/2016 12:13 PM, Yao Qi wrote:
> On Tue, Nov 8, 2016 at 10:30 AM, Matthias Pfaller <leo@marco.de> wrote:
>> Hi,
>>
>> I'm currently implementing gdb server support for our cortex-m3/m4 based
>> embedded systems.
>>
> 
> Out of curiosity, is it like openocd?

No, it is a thread running on the target.

>> At the moment I'm implementing break points using the FPB unit.
>>
> 
> I don't know much about FPB unit.

Most cortex-m? implementations have a debug/trace macro cell embedded
and the FPB unit (flash breakpoint and patch unit) is one part of the
debug subsytem. openocd is using the same facilities, just over SWD. But
you can access almost all of the functionality from the cpu as well.

That way one can debug the target even when there is no SWD-probe
attached. and you can e.g. single step one thread while the rest of the
system continues to run.

Obviously you cannot debug a complete system crash, but it is usefull
enough in a lot of cases.

>> I would like to setup the FPB unit at context switch time for thread
>> specific break points. Is there a way to pass the referenced thread id
>> with the 'Z' commands?
>>
> The remote protocol is not aware of thread specific breakpoint.
> Thread specific breakpoint just works, "b foo if thread 1", but it is not
> efficient.  What do you want to achieve?

I do not want the system to halt when I set a breakpoint in a general
library routine. So I plan to activate the breakpoints only when the
thread corresponding to the breakpoint is running.

>> Is there a way to modify the behaviour of the break point commands to
>> always reference the currently selected thread? Gobal breakpoints do not
>> make sense in my usage case.
> 
> What do you mean by "always reference the currently selected thread"?
> Always set thread specific breakpoint for current selected thread?
> You can get current thread via $_thread and $_gthread,
> https://sourceware.org/gdb/download/onlinedocs/gdb/Convenience-Vars.html
> 
>>
>> Another thing I'd really like to do is to enforce non-stop and
>> target-async from the target side. Is there a way to do this?
> 
> See the first paragraph in GDB manual below,
> https://sourceware.org/gdb/download/onlinedocs/gdb/Remote-Non_002dStop.html

I know about this. In my case all-stop will never work. At least the
gdbstub task and the idle task must never be stopped. I would like to
enforce non-stop without having to put

  set non-stop on

into my .gdbinit.

> IIUC, GDB thinks async is on in remote (if the serial device is
> async).
> 
>>
>> regards, Matthias
>>
>> PS: How does gdb recoginze the initial stack frame? At the moment stack
>> trace backs of stopped threads will not stop at correct frame.
> 
> Do you have an example?
> 

thread 2 received signal SIGINT, Interrupt.
0x00499448 in tsleep (event=<optimized out>, timeout=<optimized out>)
    at /mnt/projekt/soft/crt/save/../task.c:464
464             schedule_request(SCHEDULE_NOW);
where
#0  0x00499448 in tsleep (event=<optimized out>, timeout=<optimized out>)
    at /mnt/projekt/soft/crt/save/../task.c:464
#1  0x004bfbf2 in f83sleep (env=<optimized out>, event=<optimized out>,
    t=<optimized out>) at /mnt/projekt/soft/crt/save/../f83i16/f83sleep.c:21
#2  0x004b0246 in f83inner () at f83inner.c:3970
#3  0x0049958c in task_create (name=<optimized out>,
    initial_pc=<optimized out>, arg=..., stacksize=<optimized out>,
    priority=<optimized out>) at /mnt/projekt/soft/crt/save/../task.c:626
#4  0x74726174 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Frame #3 and frame #4 are spurious.

thanks, Matthias
-- 
Matthias Pfaller                          Software Entwicklung
marco Systemanalyse und Entwicklung GmbH  Tel   +49 8131 5161 41
Hans-Böckler-Str. 2, D 85221 Dachau       Fax   +49 8131 5161 66
http://www.marco.de/                      Email leo@marco.de
Geschäftsführer Martin Reuter             HRB 171775 Amtsgericht München


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4349 bytes --]