how to debug gdb?

Tomasz Gajewski tomga at wp.pl
Thu May 6 12:42:28 CEST 2021


Hi Alexander,


Alexander Tormasov via users <users at lists.genode.org> writes:

> the only workable solution with own gdbserver inside qemu with nova in
> this moment hangs, as described, in some attempt to upgrade quota:
> [init -> gdb_monitor] upgrading quota donation for PD session (0 bytes, 4 caps)
> [init] child "gdb_monitor" requests resources: ram_quota=0, cap_quota=4
>
> when i update a bit run file it give me another message before hang (while I give 3500 caps):
> [init] child "gdb_monitor" requests resources: cap_quota=2

Is it possible that you missed message from Christian Prochasa he sent
on April 9th? Increasing that constant helped me to further with
debugging service using gdb_monitor on Nova in qemu.

> suggested solution with nova inside qemu -s somehow work except that
> it do not see threads!  Now I found that for UP even in the very
> beginning gdb show only CPU0 single thread (while genode do create at
> least 2 - main and for signals).  for 2 CPU version it show only 2 of
> them/etc.
>
> so… still not clear for me where it the best solution to continue
>
> so far qemu -s works in faster way, while it do not see internal nova threads…
> Can we somehow force qemu to show nova threads?

Currently I stumbled on problem with threads too. I know that creating
thread using 'pthread_create' in debugged code does not raise any error
but after this call number of thread visible in gdb (using 'info
thread') does not change and breakpoint set inside a function assigned
for thread is never triggered.


Does anybody know if it is a sign of not creating thread at all or some
deficiency in 'gdb_monitor' that fails to update presented list of
threads? From the behavior it seems it is a first option.

Another question is if it is supposed to work and it doesn't only
because of some error or gdb_monitor lacks this functionality
completely?


Regards
Tomasz Gajewski



More information about the users mailing list