No support for arcv2 for Zephyr thread aware debugging

[jshoen]

I am trying to used gdb and openOCD for thread aware debugging of an ARC EMSK board configured with an EM4 CPU. I am using branch: https://github.com/zephyrproject-rtos/openocd/tree/zephyr-20190226. I built openOCD and copied to to the correct locations in the zephyr-sdk tree. I then edited the snps_em_sk_fpga.cfg file to add the '-rtos auto' option to the 'target create' line.

With these changes the openOCD tries to detect the RTOS, but errors out with a message that it cannot detect the arcv2 target:
Info : Zephyr: does it have symbol 0 (mandatory)?
Info : Zephyr: does it have symbol 1 (mandatory)?
Info : Zephyr: does it have symbol 2 (mandatory)?
Info : Zephyr: does it have symbol 3 (optional)?
Info : Zephyr: all mandatory symbols found
Info : Auto-detected RTOS: Zephyr
Info : Zephyr: looking for target: arcv2
Error: Could not find target in Zephyr compatibility list

After that attempting to list threads shows only a single thread (the idle thread) even though multiple threads are running.

When examining the Zephyr_params_list in Zephyr.c it appears that the "cortex_m" is the only supported target.

To reproduce, add the following configuration settings to one of the sample targets such as blinky.
CONFIG_DEBUG=y
CONFIG_INIT_STACKS=y
CONFIG_STACK_SENTINEL=y
CONFIG_ARC_EXCEPTION_DEBUG=y
CONFIG_LOG=y
CONFIG_OPENOCD_SUPPORT=y
Then build and attach gdb with 'make debug'.

[EvgeniiDidin]

Hi @jshoen,
I am sorry for late response.
I prepared a patch, which introduces support of arcv2 for Zephyr in openOCD:
foss-for-synopsys-dwc-arc-processors/openocd@dbe0952
Now the openocd log is:

Info : 1689 3902 Zephyr.c:673 Zephyr_detect_rtos(): Zephyr: does it have symbol 0 (mandatory)?
Info : 1690 3902 Zephyr.c:673 Zephyr_detect_rtos(): Zephyr: does it have symbol 1 (mandatory)?
Info : 1691 3902 Zephyr.c:673 Zephyr_detect_rtos(): Zephyr: does it have symbol 2 (mandatory)?
Info : 1692 3902 Zephyr.c:673 Zephyr_detect_rtos(): Zephyr: does it have symbol 3 (optional)?
Info : 1693 3902 Zephyr.c:681 Zephyr_detect_rtos(): Zephyr: all mandatory symbols found
Info : 1694 3902 rtos.c:275 rtos_qsymbol(): Auto-detected RTOS: Zephyr
Info : 1695 3902 Zephyr.c:700 Zephyr_create(): Zephyr: looking for target: arcv2
Info : 1696 3902 Zephyr.c:707 Zephyr_create(): Zephyr: target known, params at 0x8de2f8

Currently I am working on correctly reading Thread information: (gdb): info threads

Also I have a question. When you tried to run your binary have you seen such messages in serial port:

***** Exception vector: 0x6, cause code: 0x10, parameter 0x0
Address 0x40
EV_ProtV: Normal vector table in secure memory
Current thread ID = 0x80000320
Faulting instruction address = 0x40
Fatal fault in essential thread! Spinning...

or

**FATAL: ***** Exception vector: 0x6, cause code: 0x10, parameter 0x0
FATAL: Address 0x40
FATAL: Faulting instruction address = 0x40
FATAL: >>> ZEPHYR FATAL ERROR 0: CPU exception
FATAL: Current thread: 0x80000058 (unknown)
FATAL: Halting system

?
And was the result of running (gdb): info threads like:

  Id   Target Id         Frame 
* 1    Remote target     k_cpu_idle () at  /zephyr/arch/arc/core/cpu_idle.S:47

?

[jshoen]

I did not see the secure memory exception, but our platform is running without secure memory support enabled, so we would not have seen that issue. I do not believe that I saw the fatal error fault either. In my experimentally modified code I was able to list all of the thread names when I ran ‘info threads’, but I could not switch to any of the threads when I did something like ‘thread 2’. Jay From: EvgeniiDidin <[email protected]> Sent: Tuesday, August 6, 2019 12:11 PM To: zephyrproject-rtos/openocd <[email protected]> Cc: Jay Shoen <[email protected]>; Mention <[email protected]> Subject: Re: [zephyrproject-rtos/openocd] No support for arcv2 for Zephyr thread aware debugging (#10) Hi @jshoen<https://github.com/jshoen>, I am sorry for late response. I prepared a patch, which introduces support of arcv2 for Zephyr in openOCD: foss-for-synopsys-dwc-arc-processors/openocd@dbe0952<foss-for-synopsys-dwc-arc-processors/openocd@dbe0952> Now the openocd log is: Info : 1689 3902 Zephyr.c:673 Zephyr_detect_rtos(): Zephyr: does it have symbol 0 (mandatory)? Info : 1690 3902 Zephyr.c:673 Zephyr_detect_rtos(): Zephyr: does it have symbol 1 (mandatory)? Info : 1691 3902 Zephyr.c:673 Zephyr_detect_rtos(): Zephyr: does it have symbol 2 (mandatory)? Info : 1692 3902 Zephyr.c:673 Zephyr_detect_rtos(): Zephyr: does it have symbol 3 (optional)? Info : 1693 3902 Zephyr.c:681 Zephyr_detect_rtos(): Zephyr: all mandatory symbols found Info : 1694 3902 rtos.c:275 rtos_qsymbol(): Auto-detected RTOS: Zephyr Info : 1695 3902 Zephyr.c:700 Zephyr_create(): Zephyr: looking for target: arcv2 Info : 1696 3902 Zephyr.c:707 Zephyr_create(): Zephyr: target known, params at 0x8de2f8 Currently I am working on correctly reading Thread information: (gdb): info threads Also I have a question. When you tried to run your binary have you seen such messages in serial port: ***** Exception vector: 0x6, cause code: 0x10, parameter 0x0 Address 0x40 EV_ProtV: Normal vector table in secure memory Current thread ID = 0x80000320 Faulting instruction address = 0x40 Fatal fault in essential thread! Spinning... or **FATAL: ***** Exception vector: 0x6, cause code: 0x10, parameter 0x0 FATAL: Address 0x40 FATAL: Faulting instruction address = 0x40 FATAL: >>> ZEPHYR FATAL ERROR 0: CPU exception FATAL: Current thread: 0x80000058 (unknown) FATAL: Halting system ? And was the result of running (gdb): info threads like: Id Target Id Frame * 1 Remote target k_cpu_idle () at /zephyr/arch/arc/core/cpu_idle.S:47 ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#10?email_source=notifications&email_token=AMUGTR7IKR7HKPRCFUOYC33QDG5ETA5CNFSM4IEINI2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3V742Q#issuecomment-518782570>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMUGTR6ZJL7B5G2HYADT6CDQDG5ETANCNFSM4IEINI2A>.

[abrodkin]

There's an expectation to see threads-related functionality similar to Linux, in particular:

1. Ability to display information about currently available threads.
   That's already done (WIP - https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/tree/topic_zephyr_threads):

    (gdb) info threads
     Id   Target Id                                              Frame
     1    Thread 2147483648 (Name: thread_a, prio:7,useropts:0)  0x80001e20 in threadA_sem ()
     2    Thread 2147484364 (Name: sysworkq, prio:-1,useropts:0) 0x00000031 in _VectorTable ()
   * 3    Thread 2147484028 (Name: idle, prio:15,useropts:1)     k_cpu_idle ()
       at .../git/zephyrproject/zephyr/arch/arc/core/cpu_idle.S:47
     4    Thread 2147483780 (Name: thread_b, prio:7,useropts:0)  0x80001e30 in threadB_sem ()
   

2. Ability to switch to a random thread and see its context including core registers, use stack unwinding.
   That's not yet done:

    (gdb) thread 2
   Thread ID 2 has terminated.
    (gdb) info threads
     Id   Target Id                                              Frame
     1    Thread 2147483648 (Name: thread_a, prio:7,useropts:0)  0x80001e20 in threadA_sem ()
     2    Thread 2147484364 (Name: sysworkq, prio:-1,useropts:0) 0x00000031 in _VectorTable ()
   * 3    Thread 2147484028 (Name: idle, prio:15,useropts:1)     k_cpu_idle ()
       at /SCRATCH/abrodkin/Projects/sources/git/zephyrproject/zephyr/arch/arc/core/cpu_idle.S:47
     4    Thread 2147483780 (Name: thread_b, prio:7,useropts:0)  0x80001e30 in threadB_sem ()
   

[EvgeniiDidin]

Hi @jshoen,

Recently I pushed a commit in my development branch:
https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/tree/topic_zephyr_threads
Now it is possible to switch between threads and get registers with "info registers" command.
Note that only callee(r13-r25,gp,fp,r30), blink and status32 registers are saved in stack for each thread.
To demonstrate actual context switch I placed some constants in r13-r25 registers different for each thread(for thread A: 0xabcd2**, for thread B: 0xabcd1**). The GDB output is like:

(gdb) info threads
  Id   Target Id                                             Frame 
  1    Thread 2147483780 (Name: thread_b, prio:7,useropts:0) 0x00000000 in _VectorTable ()
  2    Thread 2147483648 (Name: thread_a, prio:7,useropts:0) 0x00000000 in _VectorTable ()
  3    Thread 2147483912 (Name: logging, prio:14,useropts:0) 0x00000000 in _VectorTable ()
* 4    Thread 2147484200 (Name: idle, prio:15,useropts:1)    k_cpu_idle ()
    at /home/didin/work/OpenOCD/zephyr_openocd_threads/zephyr/zephyr/arch/arc/core/cpu_idle.S:47
(gdb) thread 1
[Switching to thread 1 (Thread 2147483780)]
#0  0x00000000 in _VectorTable ()
(gdb) info registers
r0             0x0                 0
r1             0x0                 0
r2             0x0                 0
r3             0x0                 0
r4             0x0                 0
r5             0x0                 0
r6             0x0                 0
r7             0x0                 0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
r13            0x80000338          2147484472
r14            0x80000084          2147483780
r15            0x33                51
r16            0xabcd110           180146448
r17            0xabcd111           180146449
r18            0xabcd112           180146450
r19            0xabcd113           180146451
r20            0xabcd114           180146452
r21            0xabcd115           180146453
r22            0xabcd116           180146454
r23            0xabcd117           180146455
r24            0xabcd118           180146456
r25            0xabcd119           180146457
gp             0xaaaaaaaa          0xaaaaaaaa
fp             0xaaaaaaaa          0xaaaaaaaa
sp             0x0                 0x0 <_VectorTable>
ilink          0x0                 0x0 <_VectorTable>
r30            0xabcd11a           180146458
blink          0x5778              0x5778 <z_pend_curr+64>
lp_count       0x0                 0
pcl            0x200806            0x200806
pc             0x0                 0x0 <_VectorTable>
status32       0x200806            [ E0 E1 Z ]
lp_start       0x0                 0x0 <_VectorTable>
lp_end         0x0                 0x0 <_VectorTable>
....
(gdb) thread 2
[Switching to thread 2 (Thread 2147483648)]
#0  0x00000000 in _VectorTable ()
(gdb) info registers
r0             0x0                 0
r1             0x0                 0
r2             0x0                 0
r3             0x0                 0
r4             0x0                 0
r5             0x0                 0
r6             0x0                 0
r7             0x0                 0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
r13            0x80000000          2147483648
r14            0x62a0              25248
r15            0x80000338          2147484472
r16            0x33                51
r17            0xabcd211           180146705
r18            0xabcd212           180146706
r19            0xabcd213           180146707
r20            0xabcd214           180146708
r21            0xabcd215           180146709
r22            0xabcd216           180146710
r23            0xabcd217           180146711
r24            0xabcd218           180146712
r25            0xabcd219           180146713
gp             0xaaaaaaaa          0xaaaaaaaa
fp             0xaaaaaaaa          0xaaaaaaaa
sp             0x0                 0x0 <_VectorTable>
ilink          0x0                 0x0 <_VectorTable>
r30            0xabcd21a           180146714
blink          0x596c              0x596c <z_tick_sleep+104>
lp_count       0x0                 0
pcl            0x200806            0x200806
pc             0x0                 0x0 <_VectorTable>
status32       0x200806            [ E0 E1 Z ]
lp_start       0x0                 0x0 <_VectorTable>
lp_end         0x0                 0x0 <_VectorTable>
...

One important thing is that I used EMSK_EM7D board which by default has ARC_HAS_SECURE option enabled, which affects stack frame. Currently openocd reads stack considering enabled Security, but I am going to add some checks for correct handling ARC_HAS_SECURE option ASAP. Could you please tell me, does you board has ARC_HAS_SECURE option enabled?

Could you please try this revision of openocd:
foss-for-synopsys-dwc-arc-processors/openocd@6760b2a ?

[jshoen]

Hi Evgenii, We do not have the ARC_HAS_SECURE option enabled as our HW does not support that capability. Do you still want me to try your branch or should I wait until you have accounted for the ARC_HAS_SECURE option? Thanks Jay From: EvgeniiDidin <[email protected]> Sent: Wednesday, August 28, 2019 9:22 AM To: zephyrproject-rtos/openocd <[email protected]> Cc: Jay Shoen <[email protected]>; Mention <[email protected]> Subject: Re: [zephyrproject-rtos/openocd] No support for arcv2 for Zephyr thread aware debugging (#10) Hi @jshoen<https://github.com/jshoen>, Recently I pushed a commit in my development branch: https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/tree/topic_zephyr_threads Now it is possible to switch between threads and get registers with "info registers" command. Note that only callee(r13-r25,gp,fp,r30), blink and status32 registers are saved in stack for each thread. To demonstrate actual context switch I placed some constants in r13-r25 registers different for each thread(for thread A: 0xabcd2**, for thread B: 0xabcd1**). The GDB output is like: (gdb) info threads Id Target Id Frame 1 Thread 2147483780 (Name: thread_b, prio:7,useropts:0) 0x00000000 in _VectorTable () 2 Thread 2147483648 (Name: thread_a, prio:7,useropts:0) 0x00000000 in _VectorTable () 3 Thread 2147483912 (Name: logging, prio:14,useropts:0) 0x00000000 in _VectorTable () * 4 Thread 2147484200 (Name: idle, prio:15,useropts:1) k_cpu_idle () at /home/didin/work/OpenOCD/zephyr_openocd_threads/zephyr/zephyr/arch/arc/core/cpu_idle.S:47 (gdb) thread 1 [Switching to thread 1 (Thread 2147483780)] #0 0x00000000 in _VectorTable () (gdb) info registers r0 0x0 0 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 r13 0x80000338 2147484472 r14 0x80000084 2147483780 r15 0x33 51 r16 0xabcd110 180146448 r17 0xabcd111 180146449 r18 0xabcd112 180146450 r19 0xabcd113 180146451 r20 0xabcd114 180146452 r21 0xabcd115 180146453 r22 0xabcd116 180146454 r23 0xabcd117 180146455 r24 0xabcd118 180146456 r25 0xabcd119 180146457 gp 0xaaaaaaaa 0xaaaaaaaa fp 0xaaaaaaaa 0xaaaaaaaa sp 0x0 0x0 <_VectorTable> ilink 0x0 0x0 <_VectorTable> r30 0xabcd11a 180146458 blink 0x5778 0x5778 <z_pend_curr+64> lp_count 0x0 0 pcl 0x200806 0x200806 pc 0x0 0x0 <_VectorTable> status32 0x200806 [ E0 E1 Z ] lp_start 0x0 0x0 <_VectorTable> lp_end 0x0 0x0 <_VectorTable> .... (gdb) thread 2 [Switching to thread 2 (Thread 2147483648)] #0 0x00000000 in _VectorTable () (gdb) info registers r0 0x0 0 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 r13 0x80000000 2147483648 r14 0x62a0 25248 r15 0x80000338 2147484472 r16 0x33 51 r17 0xabcd211 180146705 r18 0xabcd212 180146706 r19 0xabcd213 180146707 r20 0xabcd214 180146708 r21 0xabcd215 180146709 r22 0xabcd216 180146710 r23 0xabcd217 180146711 r24 0xabcd218 180146712 r25 0xabcd219 180146713 gp 0xaaaaaaaa 0xaaaaaaaa fp 0xaaaaaaaa 0xaaaaaaaa sp 0x0 0x0 <_VectorTable> ilink 0x0 0x0 <_VectorTable> r30 0xabcd21a 180146714 blink 0x596c 0x596c <z_tick_sleep+104> lp_count 0x0 0 pcl 0x200806 0x200806 pc 0x0 0x0 <_VectorTable> status32 0x200806 [ E0 E1 Z ] lp_start 0x0 0x0 <_VectorTable> lp_end 0x0 0x0 <_VectorTable> ... One important thing is that I used EMSK_EM7D board which by default has ARC_HAS_SECURE option enabled, which affects stack frame. Currently openocd reads stack considering enabled Security, but I am going to add some checks for correct handling ARC_HAS_SECURE option ASAP. Could you please tell me, does you board has ARC_HAS_SECURE option enabled? Could you please try this revision of openocd: foss-for-synopsys-dwc-arc-processors/openocd@6760b2a<foss-for-synopsys-dwc-arc-processors/openocd@6760b2a> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#10?email_source=notifications&email_token=AMUGTRYKMCYUIIDQ4UDSXUTQG2JXVA5CNFSM4IEINI2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5LPXPI#issuecomment-525794237>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMUGTRZZ5GVDFRVTIPTGAOLQG2JXVANCNFSM4IEINI2A>.

[EvgeniiDidin]

Hi @jshoen,

To prevent you waiting my patch I think you should try my branch with such little changes:

git diff src/rtos/Zephyr.c
diff --git a/src/rtos/Zephyr.c b/src/rtos/Zephyr.c
index 9568ccc97..bdbdb7da0 100644
--- a/src/rtos/Zephyr.c
+++ b/src/rtos/Zephyr.c
@@ -203,11 +203,11 @@ static const struct stack_register_offset arc_cpu_saved[] = {
         { 30,   -1,  32 }, //r30
         { 31,   0,  32 }, //BLINK
         { 64,   -1,  32 }, // pc
-        { 67,   8,  32 } // status32  NOTE: change "8" to "4" if ARC_HAS_SECURE is disabled
+        { 67,   4,  32 } // status32  NOTE: change "8" to "4" if ARC_HAS_SECURE is disabled
 };
 
 static const struct rtos_register_stacking arc_cpu_saved_stacking = {
-       .stack_registers_size = 12,   //NOTE: change to 8 if ARC_HAS_SECURE is disabled
+       .stack_registers_size = 8,   //NOTE: change to 8 if ARC_HAS_SECURE is disabled
        .stack_growth_direction = -1,
        .num_output_registers = ARRAY_SIZE(arc_cpu_saved),
        .register_offsets = arc_cpu_saved,

I tested this on em9d(no ARC_HAS_SECURE) and it worked fine.

[EvgeniiDidin]

Hi @jshoen,

I fixed an error and added changes from previous message in the latest patch.
Could you please try the latest revision:
foss-for-synopsys-dwc-arc-processors/openocd@9dbc8a1

[jshoen]

Hi Evgenii, I tried to build with the SHA you sent, but was unable to compile due to warnings received building rtos.c and zephyr.c: src/rtos/rtos.c:303:4: error: format '%x' expects argument of type 'unsigned int *', but argument 3 has type 'threadid_t *' [-Werror=format=] sscanf(packet, "qThreadExtraInfo,%" SCNx32, &threadid); ^ src/rtos/rtos.c:408:3: error: format '%x' expects argument of type 'unsigned int *', but argument 3 has type 'threadid_t *' [-Werror=format=] sscanf(packet, "T%" SCNx32, &threadid); ^ cc1: all warnings being treated as errors src/rtos/Zephyr.c:269:2: error: missing initializer for field 'symbol_name' of 'symbol_table_elem_t' [-Werror=missing-field-initializers] { } ^ In file included from src/rtos/Zephyr.c:27:0: src/rtos/rtos.h:34:14: note: 'symbol_name' declared here const char *symbol_name; ^ src/rtos/Zephyr.c: In function 'Zephyr_fetch_thread': src/rtos/Zephyr.c:364:12: error: unused variable 'name_ptr' [-Werror=unused-variable] uint32_t name_ptr; ^ src/rtos/Zephyr.c: In function 'Zephyr_get_thread_reg_list': src/rtos/Zephyr.c:577:2: error: passing argument 3 of 'target_read_u32' from incompatible pointer type [-Werror] retval = target_read_u32(rtos->target,addr, &real_stack_addr); ^ In file included from src/rtos/Zephyr.c:29:0: ./src/target/target.h:699:5: note: expected 'uint32_t *' but argument is of type 'int64_t *' int target_read_u32(struct target *target, target_addr_t address, uint32_t *value); ^ cc1: all warnings being treated as errors src/rtos/rtos.c: In function 'rtos_thread_packet': src/rtos/rtos.c:303:4: error: format '%x' expects argument of type 'unsigned int *', but argument 3 has type 'threadid_t *' [-Werror=format=] sscanf(packet, "qThreadExtraInfo,%" SCNx32, &threadid); ^ src/rtos/rtos.c:408:3: error: format '%x' expects argument of type 'unsigned int *', but argument 3 has type 'threadid_t *' [-Werror=format=] sscanf(packet, "T%" SCNx32, &threadid); ^ cc1: all warnings being treated as errors The build is choosing to run compiler: gcc --version gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36) If I fix these errors then I can build, but I get errors when I try to list threads and only one thread is shown: Info : accepting ‘gdb’ connection on tcp/3333 0x00004054 in _svfprintf_r (data=0x0 <_reclaim_reent>, fp=0x0 <_reclaim_reent>, fmt0=<optimized out>, ap=<optimized out>) at /home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/build_arc/.build/arc-zephyr-elf/src/newlib/newlib/libc/stdio/nano-vfprintf.c:575 575 /home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/build_arc/.build/arc-zephyr-elf/src/newlib/newlib/libc/stdio/nano-vfprintf.c: No such file or directory. Info : Zephyr: does it have symbol 0 (mandatory)? Info : Zephyr: does it have symbol 1 (mandatory)? Info : Zephyr: does it have symbol 2 (mandatory)? Info : Zephyr: does it have symbol 3 (optional)? Info : Zephyr: all mandatory symbols found Info : Auto-detected RTOS: Zephyr Info : Zephyr: looking for target: arcv2 Info : Zephyr: target known, params at 0x8e2340 Error: Only size_t of 4 bytes are supported Loading section text, size 0x18d14 lma 0x0 Loading section sw_isr_table, size 0x408 lma 0x18d14 Loading section devconfig, size 0xc0 lma 0x1911c Loading section log_const_sections, size 0x50 lma 0x191dc Loading section log_backends_sections, size 0x10 lma 0x1922c Loading section shell_root_cmds_sections, size 0x68 lma 0x1923c Loading section rodata, size 0x5114 lma 0x192a4 Loading section datas, size 0x564 lma 0x8001be38 Loading section initlevel, size 0xc0 lma 0x8001c39c Loading section log_dynamic_sections, size 0x28 lma 0x8001c45c Loading section _k_sem_area, size 0x30 lma 0x8001c484 Loading section _k_mutex_area, size 0x28 lma 0x8001c4b4 Loading section _k_msgq_area, size 0x2c lma 0x8001c4dc Start address 0xe250, load size 125576 Transfer rate: 227 KB/sec, 6278 bytes/write. (gdb) c Continuing. ^Cwarning: while parsing threads: not well-formed (invalid token) [New Thread 2147486112] Thread 1 received signal SIGINT, Interrupt. [Switching to Thread 2147485052] (gdb) info threads warning: while parsing threads: not well-formed (invalid token) Id Target Id Frame Info : Getting thread -2147481184 reg list 2 Thread 2147486112 _reclaim_reent (ptr=<optimized out>) at /home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/build_arc/.build/arc-zephyr-elf/src/newlib/newlib/libc/reent/reent.c:46 The current thread <Thread ID 1> has terminated. See `help thread’. Thanks, Jay From: EvgeniiDidin <[email protected]> Sent: Thursday, August 29, 2019 7:38 AM To: zephyrproject-rtos/openocd <[email protected]> Cc: Jay Shoen <[email protected]>; Mention <[email protected]> Subject: Re: [zephyrproject-rtos/openocd] No support for arcv2 for Zephyr thread aware debugging (#10) Hi @jshoen<https://github.com/jshoen>, I fixed an error and added changes from previous message in the latest patch. Could you please try the latest revision: foss-for-synopsys-dwc-arc-processors/openocd@9dbc8a1<foss-for-synopsys-dwc-arc-processors/openocd@9dbc8a1> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#10?email_source=notifications&email_token=AMUGTRYM4LKVE4WOQXEAJSLQG7GKLA5CNFSM4IEINI2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5OQCHI#issuecomment-526188829>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMUGTR7VMZJLBDAWCZ2XLZ3QG7GKLANCNFSM4IEINI2A>.

[EvgeniiDidin]

Hi @jshoen,

Could you please revert your changes and try to configure openocd with "--disable-werror" option. After that "make" should finish without errors.

[jshoen]

Hi Evgenii, I have the same behavior if I build with disable-werror. Thanks, Jay From: EvgeniiDidin <[email protected]> Sent: Friday, August 30, 2019 1:20 PM To: zephyrproject-rtos/openocd <[email protected]> Cc: Jay Shoen <[email protected]>; Mention <[email protected]> Subject: Re: [zephyrproject-rtos/openocd] No support for arcv2 for Zephyr thread aware debugging (#10) Hi @jshoen<https://github.com/jshoen>, Could you please revert your changes and try to configure openocd with "--disable-werror" option. After that "make" should finish without errors. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#10?email_source=notifications&email_token=AMUGTR4DEPBCRQGQS6DQKJLQHFXEHA5CNFSM4IEINI2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5SRJXQ#issuecomment-526718174>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMUGTR6SMLEZUXIMBVNXZL3QHFXEHANCNFSM4IEINI2A>.

[EvgeniiDidin]

Hi Jay,

The series of patches, which introduces Zephyr thread aware debugging for arcv2 is already in zephyr-20191003 branch:
#15
#17

Also I created a patch for GDB, which is necessary for OpenOCD<->Zephyr thread aware debugging on ARC:
http://patchwork.sourceware.org/patch/35764/
zephyrproject-rtos/sdk-ng#146

I guess the issue is resolved, Zephyr thread aware debugging for arcv2 now is supported.

[EvgeniiDidin]

Hi Jay,
I'm wondering if you still have any issues with YYY then I'd like to get more details about that.
Also please note that the next Zephyr release v2.1 is going to be published soon (see https://lists.zephyrproject.org/g/announce/message/76) and would be really good to have that issue closed by the time of release so we may claim Zephyr thread-aware debugging support for ARC is now in place and known to work.

[jshoen]

Hi Evgenii, Thank you for the update. I will try to confirm functionality and provide you feedback by the end of this week. Best Regards, Jay From: EvgeniiDidin <[email protected]> Sent: Monday, November 11, 2019 2:56 AM To: zephyrproject-rtos/openocd <[email protected]> Cc: Jay Shoen <[email protected]>; Mention <[email protected]> Subject: Re: [zephyrproject-rtos/openocd] No support for arcv2 for Zephyr thread aware debugging (#10) Hi Jay, I'm wondering if you still have any issues with YYY then I'd like to get more details about that. Also please note that the next Zephyr release v2.1 is going to be published soon (see https://lists.zephyrproject.org/g/announce/message/76) and would be really good to have that issue closed by the time of release so we may claim Zephyr thread-aware debugging support for ARC is now in place and known to work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#10?email_source=notifications&email_token=AMUGTRYEWCQGTMR4X3OG4STQTET3HA5CNFSM4IEINI2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDWIU3A#issuecomment-552372844>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMUGTR6PZE7JM3XPC4W3IYTQTET3HANCNFSM4IEINI2A>.

[jshoen]

Hi Evgenii, I can confirm that the ARC Zephyr thread aware debugging is working for us. With an app running 7 threads I was able to list all of the threads, switch between the threads in gdb, view stack backtraces and move up and down the stack frames. I was also able to continue the application, break and repeat the process multiple times. Thanks very much for your support on this. It will be very useful to us. Best Regards, Jay From: EvgeniiDidin <[email protected]> Sent: Monday, November 11, 2019 2:56 AM To: zephyrproject-rtos/openocd <[email protected]> Cc: Jay Shoen <[email protected]>; Mention <[email protected]> Subject: Re: [zephyrproject-rtos/openocd] No support for arcv2 for Zephyr thread aware debugging (#10) Hi Jay, I'm wondering if you still have any issues with YYY then I'd like to get more details about that. Also please note that the next Zephyr release v2.1 is going to be published soon (see https://lists.zephyrproject.org/g/announce/message/76) and would be really good to have that issue closed by the time of release so we may claim Zephyr thread-aware debugging support for ARC is now in place and known to work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#10?email_source=notifications&email_token=AMUGTRYEWCQGTMR4X3OG4STQTET3HA5CNFSM4IEINI2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDWIU3A#issuecomment-552372844>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMUGTR6PZE7JM3XPC4W3IYTQTET3HANCNFSM4IEINI2A>.