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 _______________________________________________ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
