how to debug gdb?

[Alexander Tormasov]

	Hi Norman,

> For your debugging purposes, you may try side-stepping the seccomp-based
> sandboxing by placing an early return at the beginning of the
> 'binary_ready_hook_for_platform' in 'base-linux/src/lib/base/platform.cc'.
> 
> [1]
> https://genode.org/documentation/release-notes/20.05#Capability-based_security_using_seccomp_on_Linux

after this patch it start working - while linux version of mmap allocation fails, can’\t give me requested addresses ranges (I try a couple of them, need to investigate more - probably mmap do not flexible here).

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.

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

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?

Alexander