Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* embedded system and "target remote"
@ 2016-11-08 10:31 Matthias Pfaller
  2016-11-08 11:14 ` Yao Qi
  0 siblings, 1 reply; 4+ messages in thread
From: Matthias Pfaller @ 2016-11-08 10:31 UTC (permalink / raw)
  To: gdb

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

Hi,

I'm currently implementing gdb server support for our cortex-m3/m4 based
embedded systems.

At the moment I have the following things working:
- reading and writing memory
- reading and writing registers
- thread info
- stopping/resuming threads
- single stepping a thread

At the moment I'm implementing break points using the FPB unit.

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?

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.

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?

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.
-- 
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 --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: embedded system and "target remote"
  2016-11-08 10:31 embedded system and "target remote" Matthias Pfaller
@ 2016-11-08 11:14 ` Yao Qi
  2016-11-08 12:17   ` Matthias Pfaller
  2016-11-09  9:52   ` Matthias Pfaller
  0 siblings, 2 replies; 4+ messages in thread
From: Yao Qi @ 2016-11-08 11:14 UTC (permalink / raw)
  To: Matthias Pfaller; +Cc: GDB

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?

>
> At the moment I'm implementing break points using the FPB unit.
>

I don't know much about FPB unit.

> 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?

> 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

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?

-- 
Yao (齐尧)


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: embedded system and "target remote"
  2016-11-08 11:14 ` Yao Qi
@ 2016-11-08 12:17   ` Matthias Pfaller
  2016-11-09  9:52   ` Matthias Pfaller
  1 sibling, 0 replies; 4+ messages in thread
From: Matthias Pfaller @ 2016-11-08 12:17 UTC (permalink / raw)
  To: Yao Qi, gdb

[-- 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 --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: embedded system and "target remote"
  2016-11-08 11:14 ` Yao Qi
  2016-11-08 12:17   ` Matthias Pfaller
@ 2016-11-09  9:52   ` Matthias Pfaller
  1 sibling, 0 replies; 4+ messages in thread
From: Matthias Pfaller @ 2016-11-09  9:52 UTC (permalink / raw)
  To: gdb


[-- Attachment #1.1: Type: text/plain, Size: 1132 bytes --]

Hi,

I have done a patch that hands down thread information to remote.c.
As this is the first time I had a look at the gdb sources I'm pretty
sure my code is not suitable for integration...

The patch has (at least) the following problems:

- the thread id is needed in bp_target_info because this is what
remote.c will get. Because of this I now have the thread id in three
places (bp_location.thread, bp_location.overlay_target_info.thread and
bp_location.target_info.thread).

- there is no way to turn this off (I have no idea how this would
normally be handled)

- I have extended the Z0/Z1/z0/z1 to provide an additional parameter
(the thread id) when target_info.thread is >= 0.


regards, Matthias

PS: The stub code will hopefully follow in a couple of days.
-- 
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 #1.2: gdb-patch --]
[-- Type: text/plain, Size: 4417 bytes --]

--- ../orig/gdb/breakpoint.c
+++ ./gdb/breakpoint.c
@@ -7267,7 +7267,8 @@
     /* We compare bp_location.length in order to cover ranged breakpoints.  */
     return (breakpoint_address_match (loc1->pspace->aspace, loc1->address,
 				     loc2->pspace->aspace, loc2->address)
-	    && loc1->length == loc2->length);
+	    && loc1->length == loc2->length
+	    && loc1->thread == loc2->thread);
 }
 
 static void
@@ -7354,6 +7355,10 @@
   loc->cond_bytecode = NULL;
   loc->shlib_disabled = 0;
   loc->enabled = 1;
+  loc->thread = owner->thread;
+  loc->target_info.thread = owner->thread;
+  loc->overlay_target_info.thread = owner->thread;
+  loc->thread = owner->thread;
 
   switch (owner->type)
     {
@@ -8984,6 +8989,9 @@
   copy->loc->line_number = orig->loc->line_number;
   copy->loc->symtab = orig->loc->symtab;
   copy->loc->enabled = loc_enabled;
+  copy->loc->thread = orig->loc->thread;
+  copy->loc->target_info.thread = orig->loc->thread;
+  copy->loc->overlay_target_info.thread = orig->loc->thread;
   copy->frame_id = orig->frame_id;
   copy->thread = orig->thread;
   copy->pspace = orig->pspace;
@@ -9302,6 +9310,9 @@
 	{
 	  init_raw_breakpoint (b, gdbarch, sal, type, ops);
 	  b->thread = thread;
+	  b->loc->thread = thread;
+	  b->loc->target_info.thread = thread;
+	  b->loc->overlay_target_info.thread = thread;
 	  b->task = task;
 
 	  b->cond_string = cond_string;
@@ -9655,6 +9666,10 @@
   *task = 0;
   *rest = NULL;
 
+  /* default to current thread on non-stop targets */
+  if (target_is_non_stop_p ())
+    *thread = inferior_thread ()->global_num;
+
   while (tok && *tok)
     {
       const char *end_tok;
@@ -9946,6 +9961,9 @@
 	    }
 	  b->cond_string = cond_string;
 	  b->thread = thread;
+	  b->loc->thread = thread;
+	  b->loc->target_info.thread = thread;
+	  b->loc->overlay_target_info.thread = thread;
 	}
 
       /* Create a private copy of any extra string.  */
--- ../orig/gdb/breakpoint.h
+++ ./gdb/breakpoint.h
@@ -279,6 +279,9 @@
   /* Flag that is true if the breakpoint should be left in place even
      when GDB is not connected.  */
   int persist;
+
+  /* Thread identifier for which this breakpoint should be activated */
+  int thread;
 };
 
 /* GDB maintains two types of information about each breakpoint (or
@@ -399,7 +402,8 @@
   char duplicate;
 
   /* If we someday support real thread-specific breakpoints, then
-     the breakpoint location will need a thread identifier.  */
+     the breakpoint location will need a thread identifier. */
+  int thread;
 
   /* Data for specific breakpoint types.  These could be a union, but
      simplicity is more important than memory usage for breakpoints.  */
--- ../orig/gdb/remote.c
+++ ./gdb/remote.c
@@ -9300,7 +9300,12 @@
       addr = (ULONGEST) remote_address_masked (addr);
       p += hexnumstr (p, addr);
       xsnprintf (p, endbuf - p, ",%d", bpsize);
-
+      p += strlen(p);
+      if (bp_tgt->thread >= 0)
+        {
+	  *(p++) = ',';
+	  write_ptid (p, endbuf, global_thread_id_to_ptid (bp_tgt->thread));
+        }
       if (remote_supports_cond_breakpoints (ops))
 	remote_add_target_side_condition (gdbarch, bp_tgt, p, endbuf);
 
@@ -9358,6 +9363,12 @@
       addr = (ULONGEST) remote_address_masked (bp_tgt->placed_address);
       p += hexnumstr (p, addr);
       xsnprintf (p, endbuf - p, ",%d", bp_tgt->placed_size);
+      p += strlen(p);
+      if (bp_tgt->thread >= 0)
+        {
+	  *(p++) = ',';
+	  write_ptid (p, endbuf, global_thread_id_to_ptid (bp_tgt->thread));
+        }
 
       putpkt (rs->buf);
       getpkt (&rs->buf, &rs->buf_size, 0);
@@ -9619,6 +9630,12 @@
   addr = remote_address_masked (addr);
   p += hexnumstr (p, (ULONGEST) addr);
   xsnprintf (p, endbuf - p, ",%x", bpsize);
+  p += strlen(p);
+  if (bp_tgt->thread >= 0)
+    {
+      *(p++) = ',';
+      write_ptid (p, endbuf, global_thread_id_to_ptid (bp_tgt->thread));
+    }
 
   if (remote_supports_cond_breakpoints (self))
     remote_add_target_side_condition (gdbarch, bp_tgt, p, endbuf);
@@ -9675,6 +9692,12 @@
   addr = remote_address_masked (bp_tgt->placed_address);
   p += hexnumstr (p, (ULONGEST) addr);
   xsnprintf (p, endbuf  - p, ",%x", bp_tgt->placed_size);
+  p += strlen(p);
+  if (bp_tgt->thread >= 0)
+    {
+      *(p++) = ',';
+      write_ptid (p, endbuf, global_thread_id_to_ptid (bp_tgt->thread));
+    }
 
   putpkt (rs->buf);
   getpkt (&rs->buf, &rs->buf_size, 0);

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-11-09  9:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-08 10:31 embedded system and "target remote" Matthias Pfaller
2016-11-08 11:14 ` Yao Qi
2016-11-08 12:17   ` Matthias Pfaller
2016-11-09  9:52   ` Matthias Pfaller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox