Hi Alexander,
Alexander Tormasov via users users@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