posix blocking in gdb

posix blocking in gdb

[C Smith]

I am debugging a Cobalt userspace real time app (using posix/alchemy
skins) on Xenomai 3.1, X86 platform. I have a problem with my process
blocking when I am single-stepping in gdb (although the process does
not block when it is run full speed). This happens with ioctl(),
write() or read() of a rtdm device.

If the code does an ioctl() for instance, this is invoked:
in rtdm.c
COBALT_IMPL(int, ioctl, (int fd, unsigned int request, ...))
   ret = do_ioctl(fd, request, arg);
which calls
 static int do_ioctl(int fd, unsigned int request, void *arg)
   ret = XENOMAI_SYSCALL3(sc_cobalt_ioctl, fd, request, arg);

 and my process blocks on the call to XENOMAI_SYSCALL3() so I cannot
step over this code. If I interrupt gdb, it says:
  0xf7fceb69 in __kernel_vsyscall ()Which basically means my process
was blocked.

I imagine the problem is caused by a difference between
primary/secondary modes and their ability to access the Cobalt posix
wrappers? The problem is that I need to step over
read()/write()/ioctl() while in gdb. Is there any way to do so ?

thanks, -C Smith

Re: posix blocking in gdb

[Jan Kiszka]

On 20.11.21 09:10, C Smith via Xenomai wrote:
> I am debugging a Cobalt userspace real time app (using posix/alchemy
> skins) on Xenomai 3.1, X86 platform. I have a problem with my process
> blocking when I am single-stepping in gdb (although the process does
> not block when it is run full speed). This happens with ioctl(),
> write() or read() of a rtdm device.
> 
> If the code does an ioctl() for instance, this is invoked:
> in rtdm.c
> COBALT_IMPL(int, ioctl, (int fd, unsigned int request, ...))
>    ret = do_ioctl(fd, request, arg);
> which calls
>  static int do_ioctl(int fd, unsigned int request, void *arg)
>    ret = XENOMAI_SYSCALL3(sc_cobalt_ioctl, fd, request, arg);
> 
>  and my process blocks on the call to XENOMAI_SYSCALL3() so I cannot
> step over this code. If I interrupt gdb, it says:
>   0xf7fceb69 in __kernel_vsyscall ()Which basically means my process
> was blocked.
> 
> I imagine the problem is caused by a difference between
> primary/secondary modes and their ability to access the Cobalt posix
> wrappers? The problem is that I need to step over
> read()/write()/ioctl() while in gdb. Is there any way to do so ?
> 

Debugging, including single stepping, is supposed to work under Xenomai
as well (that's why there is smokey's gdb test).

Could you trace (trace-cmd record -e "cobalt*" -e sched -e signal) the
problematic sequence? Do you see the issue also with in-tree drivers
backing those read/write/ioctl requests?

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux