All of lore.kernel.org
 help / color / mirror / Atom feed
* Problem with gdb
@ 2020-04-25  7:18 Paolo Minazzi
  2020-04-26  8:33 ` Jan Kiszka
  0 siblings, 1 reply; 5+ messages in thread
From: Paolo Minazzi @ 2020-04-25  7:18 UTC (permalink / raw)
  To: xenomai

I'm Paolo Minazzi.
I am working on an ARM board with iMX6SX.

Linux kernel : 4.9
Ipipe        : ipipe-core-4.9.38-arm-3.patch
Xenomai      : 3.1

All works well.
I have a problem debugging with GDB (both native and remote).
The problem is that before an alchemy small demo starts, I have the hit 
2 times CTRL-C and use "c" command.

Details:
[1] gdb demo
[2] I use the "r" command to run.
     gdb remain blocked
[3] I press CTRL-C, then "c" command.
     gdb remain blocked
[4] I press CTRL-C, then "c" command.
     Then demo start correctly

Can you help me ?

Kind regards,
Paolo Minazzi


EXTRA DETAILS
=============

GDB SESSION
         GNU gdb (GDB) 7.12
         Copyright (C) 2016 Free Software Foundation, Inc.
         License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
         This is free software: you are free to change and redistribute it.
         There is NO WARRANTY, to the extent permitted by law. Type 
"show copying"
         and "show warranty" for details.
         This GDB was configured as "arm-linux-gnueabihf".
         Type "show configuration" for configuration details.
         For bug reporting instructions, please see:
         <http://www.gnu.org/software/gdb/bugs/>.
         Find the GDB manual and other documentation resources online at:
         <http://www.gnu.org/software/gdb/documentation/>.
         For help, type "help".
         Type "apropos word" to search for commands related to "word"...
         Reading symbols from demo...done.
                 (gdb) r
         Starting program: /demo
         [Thread debugging using libthread_db enabled]
         Using host libthread_db library "/lib/libthread_db.so.1".
         [New Thread 0xb6c61470 (LWP 432)]
                 <<< BLOCKED. I press CTRL-C >>>
         Thread 1 "demo" received signal SIGINT, Interrupt.
         0xb6fa4d08 in __wrap_pthread_mutex_lock () from /lib/libcobalt.so.2
                 (gdb) c
         Continuing.
                 <<< BLOCKED. I press CTRL-C >>>
         Thread 1 "demo" received signal SIGINT, Interrupt.
         0xb6fa4d08 in __wrap_pthread_mutex_lock () from /lib/libcobalt.so.2
                 (gdb) c
         Continuing.
                 <<< NOW DEMO RUN CORRECTLY >>>

BACKTRACE
         If at [3] I use backtrace gdb command:
                 (gdb) backtrace
                 #0  0xb6fa4d08 in __wrap_pthread_mutex_lock () from 
/lib/libcobalt.so.2
                 #1  0xb6fa8cb2 in add_extent () from /lib/libcobalt.so.2
                 #2  0xb6fa9122 in heapmem_init () from /lib/libcobalt.so.2
                 #3  0xb6fc0db2 in heapobj_pkg_init_private () from 
/lib/libcopperplate.so.0
                 #4  0xb6fbe9d4 in copperplate_init () from 
/lib/libcopperplate.so.0
                 #5  0xb6fa9ae2 in __xenomai_init () from 
/lib/libcobalt.so.2
                 #6  0xb6fa9fbe in xenomai_init () from /lib/libcobalt.so.2
                 #7  0x00008928 in xenomai_bootstrap ()
                 #8  0x00008b64 in __libc_csu_init ()
                 #9  0xb6e7af98 in __libc_start_main () from /lib/libc.so.6
                 #10 0x00008966 in _start ()
                 Backtrace stopped: previous frame identical to this 
frame (corrupt stack?)

         If at [4] I use backtrace gdb command:
                 (gdb) backtrace
                 #0  0xb6fa4d08 in __wrap_pthread_mutex_lock () from 
/lib/libcobalt.so.2
                 #1  0xb6fa8d9a in heapmem_alloc () from /lib/libcobalt.so.2
                 #2  0xb6fbfaec in __threadobj_alloc () from 
/lib/libcopperplate.so.0
                 #3  0xb6fc0318 in threadobj_pkg_init () from 
/lib/libcopperplate.so.0
                 #4  0xb6fbea28 in copperplate_init () from 
/lib/libcopperplate.so.0
                 #5  0xb6fa9ae2 in __xenomai_init () from 
/lib/libcobalt.so.2
                 #6  0xb6fa9fbe in xenomai_init () from /lib/libcobalt.so.2
                 #7  0x00008928 in xenomai_bootstrap ()
                 #8  0x00008b64 in __libc_csu_init ()
                 #9  0xb6e7af98 in __libc_start_main () from /lib/libc.so.6
                 #10 0x00008966 in _start ()
                 Backtrace stopped: previous frame identical to this 
frame (corrupt stack?)


/proc/xenomai/sched
         When gdb is blocked ([3] and [4]) I always have this situation:
                 /# cat /proc/xenomai/sched/stat
                 CPU  PID    MSW        CSW        XSC        PF 
STAT       %CPU  NAME
                   0  0      0          779        0          0 
00018000  100.0  [ROOT]
                   0  19165  1          1          4          0 
00460040    0.0  demo
                   0  0      0          39725      0          0 
00000000    0.0  [IRQ16: [timer]]


DEMO.c
=====================================================================
         #include <stdio.h>
         #include <alchemy/task.h>

         RT_TASK rt_task;
         volatile unsigned int cnt;

         void rt_inc_fn(void *dummy) {
                 while(1) {
                         cnt++;
                         rt_task_sleep(100*1000*1000);
                 }
         }

         int main(int argc, char **argv) {
                 int ret;
                 ret = rt_task_create(&rt_task, "demo", 0, 50, 0);
                 assert(ret==0);
                 ret = rt_task_start(&rt_task, &rt_inc_fn, NULL);
                 assert(ret==0);
                  while(1) {
                         usleep(1000000);
                         printf("%d\n", cnt);
                 }
         }
=====================================================================



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

* Re: Problem with gdb
  2020-04-25  7:18 Problem with gdb Paolo Minazzi
@ 2020-04-26  8:33 ` Jan Kiszka
  2020-04-26 12:50   ` Paolo Minazzi
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Kiszka @ 2020-04-26  8:33 UTC (permalink / raw)
  To: Paolo Minazzi, xenomai

On 25.04.20 09:18, Paolo Minazzi via Xenomai wrote:
> I'm Paolo Minazzi.
> I am working on an ARM board with iMX6SX.
> 
> Linux kernel : 4.9
> Ipipe        : ipipe-core-4.9.38-arm-3.patch

Can you cross-check with ipipe-core-4.19.114-cip24-arm-08? 4.9 is 
unmaintained regarding I-pipe.

> Xenomai      : 3.1
> 
> All works well.
> I have a problem debugging with GDB (both native and remote).
> The problem is that before an alchemy small demo starts, I have the hit 
> 2 times CTRL-C and use "c" command.
> 
> Details:
> [1] gdb demo
> [2] I use the "r" command to run.
>      gdb remain blocked
> [3] I press CTRL-C, then "c" command.
>      gdb remain blocked
> [4] I press CTRL-C, then "c" command.
>      Then demo start correctly
> 
> Can you help me ?
> 

How did you build Xenomai (configure options)? How are you building your 
demo?

Jan

> Kind regards,
> Paolo Minazzi
> 
> 
> EXTRA DETAILS
> =============
> 
> GDB SESSION
>          GNU gdb (GDB) 7.12
>          Copyright (C) 2016 Free Software Foundation, Inc.
>          License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
>          This is free software: you are free to change and redistribute it.
>          There is NO WARRANTY, to the extent permitted by law. Type 
> "show copying"
>          and "show warranty" for details.
>          This GDB was configured as "arm-linux-gnueabihf".
>          Type "show configuration" for configuration details.
>          For bug reporting instructions, please see:
>          <http://www.gnu.org/software/gdb/bugs/>.
>          Find the GDB manual and other documentation resources online at:
>          <http://www.gnu.org/software/gdb/documentation/>.
>          For help, type "help".
>          Type "apropos word" to search for commands related to "word"...
>          Reading symbols from demo...done.
>                  (gdb) r
>          Starting program: /demo
>          [Thread debugging using libthread_db enabled]
>          Using host libthread_db library "/lib/libthread_db.so.1".
>          [New Thread 0xb6c61470 (LWP 432)]
>                  <<< BLOCKED. I press CTRL-C >>>
>          Thread 1 "demo" received signal SIGINT, Interrupt.
>          0xb6fa4d08 in __wrap_pthread_mutex_lock () from 
> /lib/libcobalt.so.2
>                  (gdb) c
>          Continuing.
>                  <<< BLOCKED. I press CTRL-C >>>
>          Thread 1 "demo" received signal SIGINT, Interrupt.
>          0xb6fa4d08 in __wrap_pthread_mutex_lock () from 
> /lib/libcobalt.so.2
>                  (gdb) c
>          Continuing.
>                  <<< NOW DEMO RUN CORRECTLY >>>
> 
> BACKTRACE
>          If at [3] I use backtrace gdb command:
>                  (gdb) backtrace
>                  #0  0xb6fa4d08 in __wrap_pthread_mutex_lock () from 
> /lib/libcobalt.so.2
>                  #1  0xb6fa8cb2 in add_extent () from /lib/libcobalt.so.2
>                  #2  0xb6fa9122 in heapmem_init () from /lib/libcobalt.so.2
>                  #3  0xb6fc0db2 in heapobj_pkg_init_private () from 
> /lib/libcopperplate.so.0
>                  #4  0xb6fbe9d4 in copperplate_init () from 
> /lib/libcopperplate.so.0
>                  #5  0xb6fa9ae2 in __xenomai_init () from 
> /lib/libcobalt.so.2
>                  #6  0xb6fa9fbe in xenomai_init () from /lib/libcobalt.so.2
>                  #7  0x00008928 in xenomai_bootstrap ()
>                  #8  0x00008b64 in __libc_csu_init ()
>                  #9  0xb6e7af98 in __libc_start_main () from /lib/libc.so.6
>                  #10 0x00008966 in _start ()
>                  Backtrace stopped: previous frame identical to this 
> frame (corrupt stack?)
> 
>          If at [4] I use backtrace gdb command:
>                  (gdb) backtrace
>                  #0  0xb6fa4d08 in __wrap_pthread_mutex_lock () from 
> /lib/libcobalt.so.2
>                  #1  0xb6fa8d9a in heapmem_alloc () from 
> /lib/libcobalt.so.2
>                  #2  0xb6fbfaec in __threadobj_alloc () from 
> /lib/libcopperplate.so.0
>                  #3  0xb6fc0318 in threadobj_pkg_init () from 
> /lib/libcopperplate.so.0
>                  #4  0xb6fbea28 in copperplate_init () from 
> /lib/libcopperplate.so.0
>                  #5  0xb6fa9ae2 in __xenomai_init () from 
> /lib/libcobalt.so.2
>                  #6  0xb6fa9fbe in xenomai_init () from /lib/libcobalt.so.2
>                  #7  0x00008928 in xenomai_bootstrap ()
>                  #8  0x00008b64 in __libc_csu_init ()
>                  #9  0xb6e7af98 in __libc_start_main () from /lib/libc.so.6
>                  #10 0x00008966 in _start ()
>                  Backtrace stopped: previous frame identical to this 
> frame (corrupt stack?)
> 
> 
> /proc/xenomai/sched
>          When gdb is blocked ([3] and [4]) I always have this situation:
>                  /# cat /proc/xenomai/sched/stat
>                  CPU  PID    MSW        CSW        XSC        PF 
> STAT       %CPU  NAME
>                    0  0      0          779        0          0 
> 00018000  100.0  [ROOT]
>                    0  19165  1          1          4          0 
> 00460040    0.0  demo
>                    0  0      0          39725      0          0 
> 00000000    0.0  [IRQ16: [timer]]
> 
> 
> DEMO.c
> =====================================================================
>          #include <stdio.h>
>          #include <alchemy/task.h>
> 
>          RT_TASK rt_task;
>          volatile unsigned int cnt;
> 
>          void rt_inc_fn(void *dummy) {
>                  while(1) {
>                          cnt++;
>                          rt_task_sleep(100*1000*1000);
>                  }
>          }
> 
>          int main(int argc, char **argv) {
>                  int ret;
>                  ret = rt_task_create(&rt_task, "demo", 0, 50, 0);
>                  assert(ret==0);
>                  ret = rt_task_start(&rt_task, &rt_inc_fn, NULL);
>                  assert(ret==0);
>                   while(1) {
>                          usleep(1000000);
>                          printf("%d\n", cnt);
>                  }
>          }
> =====================================================================
> 
> 

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


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

* Re: Problem with gdb
  2020-04-26  8:33 ` Jan Kiszka
@ 2020-04-26 12:50   ` Paolo Minazzi
  2020-04-27  5:39     ` Jan Kiszka
  0 siblings, 1 reply; 5+ messages in thread
From: Paolo Minazzi @ 2020-04-26 12:50 UTC (permalink / raw)
  To: Jan Kiszka, xenomai

Il 26/04/2020 10:33, Jan Kiszka ha scritto:
> Can you cross-check with ipipe-core-4.19.114-cip24-arm-08? 4.9 is 
> unmaintained regarding I-pipe.
Hi Jan,
I could try 4.19. But then I would have a complex task to to the porting 
all of my system to linux-4.19.

I have tried now downgrading xenomai to 3.0.9 with the same ipipe-4.9.38.
I have seen something changed in xenomai 3.1 about debugging.
With xenomai-3.0.9 gdb seems working OK.
Tomorrow I will test better and I will post results.

> How did you build Xenomai (configure options)? How are you building 
> your demo?
>
Xenomai build

./scripts/bootstrap --with-core=cobalt
configure --build=i686-pc-linux-gnu \
--host=arm-linux-gnueabihf \
--with-core=cobalt \
--prefix=$HERE/../$XENOMAI-install \
CC=arm-linux-gnueabihf-gcc LD=arm-linux-gnueabihf-ld
make

Application build

CROSS=arm-linux-gnueabihf-

INCLUDES=$(shell sh ../../xenomai-3.1-install/bin/xeno-config 
--skin=alchemy --cflags)
LIBS=$(shell sh ../../xenomai-3.1-install/bin/xeno-config --skin=alchemy 
--ldflags)

All:
         $(CROSS)gcc $(INCLUDES) $(LIBS) -o demo demo.c -g


Kind regards,
Paolo



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

* Re: Problem with gdb
  2020-04-26 12:50   ` Paolo Minazzi
@ 2020-04-27  5:39     ` Jan Kiszka
  2020-04-27  9:30       ` Paolo Minazzi
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Kiszka @ 2020-04-27  5:39 UTC (permalink / raw)
  To: Paolo Minazzi, xenomai

On 26.04.20 14:50, Paolo Minazzi wrote:
> Il 26/04/2020 10:33, Jan Kiszka ha scritto:
>> Can you cross-check with ipipe-core-4.19.114-cip24-arm-08? 4.9 is 
>> unmaintained regarding I-pipe.
> Hi Jan,
> I could try 4.19. But then I would have a complex task to to the porting 
> all of my system to linux-4.19.

If you aren't being a lab device, this would be better anyway in order 
to receive bug fixes for a longer time. As I said: 4.9 is dead, already 
lagging behind. 4.4-cip is still maintained but a bad start for a new 
project.

> 
> I have tried now downgrading xenomai to 3.0.9 with the same ipipe-4.9.38.
> I have seen something changed in xenomai 3.1 about debugging.

Yes, we need 
https://gitlab.denx.de/Xenomai/ipipe-arm/-/commit/5f032ff0126222ee944e4e44ea0c2b49a9c66d02 
and more.

Jan

> With xenomai-3.0.9 gdb seems working OK.
> Tomorrow I will test better and I will post results.
> 
>> How did you build Xenomai (configure options)? How are you building 
>> your demo?
>>
> Xenomai build
> 
> ./scripts/bootstrap --with-core=cobalt
> configure --build=i686-pc-linux-gnu \
> --host=arm-linux-gnueabihf \
> --with-core=cobalt \
> --prefix=$HERE/../$XENOMAI-install \
> CC=arm-linux-gnueabihf-gcc LD=arm-linux-gnueabihf-ld
> make
> 
> Application build
> 
> CROSS=arm-linux-gnueabihf-
> 
> INCLUDES=$(shell sh ../../xenomai-3.1-install/bin/xeno-config 
> --skin=alchemy --cflags)
> LIBS=$(shell sh ../../xenomai-3.1-install/bin/xeno-config --skin=alchemy 
> --ldflags)
> 
> All:
>          $(CROSS)gcc $(INCLUDES) $(LIBS) -o demo demo.c -g
> 
> 
> Kind regards,
> Paolo
> 

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


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

* Re: Problem with gdb
  2020-04-27  5:39     ` Jan Kiszka
@ 2020-04-27  9:30       ` Paolo Minazzi
  0 siblings, 0 replies; 5+ messages in thread
From: Paolo Minazzi @ 2020-04-27  9:30 UTC (permalink / raw)
  To: Jan Kiszka, xenomai

Il 27/04/2020 07:39, Jan Kiszka ha scritto:
> On 26.04.20 14:50, Paolo Minazzi wrote:
>> Il 26/04/2020 10:33, Jan Kiszka ha scritto:
>>> Can you cross-check with ipipe-core-4.19.114-cip24-arm-08? 4.9 is 
>>> unmaintained regarding I-pipe.
>> Hi Jan,
>> I could try 4.19. But then I would have a complex task to to the 
>> porting all of my system to linux-4.19.
>
> If you aren't being a lab device, this would be better anyway in order 
> to receive bug fixes for a longer time. As I said: 4.9 is dead, 
> already lagging behind. 4.4-cip is still maintained but a bad start 
> for a new project.
Hi Jan,

Ok, I'm trying to port my system to 4.19.

I confirm that gdb with

- xenomai-3.0.9
- ipipe4-9

works correctly.

Kind regards,
Paolo
>
>>
>> I have tried now downgrading xenomai to 3.0.9 with the same 
>> ipipe-4.9.38.
>> I have seen something changed in xenomai 3.1 about debugging.
>
> Yes, we need 
> https://gitlab.denx.de/Xenomai/ipipe-arm/-/commit/5f032ff0126222ee944e4e44ea0c2b49a9c66d02 
> and more.
>
> Jan
>
>> With xenomai-3.0.9 gdb seems working OK.
>> Tomorrow I will test better and I will post results.
>>
>>> How did you build Xenomai (configure options)? How are you building 
>>> your demo?
>>>
>> Xenomai build
>>
>> ./scripts/bootstrap --with-core=cobalt
>> configure --build=i686-pc-linux-gnu \
>> --host=arm-linux-gnueabihf \
>> --with-core=cobalt \
>> --prefix=$HERE/../$XENOMAI-install \
>> CC=arm-linux-gnueabihf-gcc LD=arm-linux-gnueabihf-ld
>> make
>>
>> Application build
>>
>> CROSS=arm-linux-gnueabihf-
>>
>> INCLUDES=$(shell sh ../../xenomai-3.1-install/bin/xeno-config 
>> --skin=alchemy --cflags)
>> LIBS=$(shell sh ../../xenomai-3.1-install/bin/xeno-config 
>> --skin=alchemy --ldflags)
>>
>> All:
>>          $(CROSS)gcc $(INCLUDES) $(LIBS) -o demo demo.c -g
>>
>>
>> Kind regards,
>> Paolo
>>
>



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

end of thread, other threads:[~2020-04-27  9:30 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-25  7:18 Problem with gdb Paolo Minazzi
2020-04-26  8:33 ` Jan Kiszka
2020-04-26 12:50   ` Paolo Minazzi
2020-04-27  5:39     ` Jan Kiszka
2020-04-27  9:30       ` Paolo Minazzi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.