Hi Norman, This worked, but I am still not out of the woods. First, there seems to be a signal quota issue (although I think this may be OK as more quota is requested dynamically?). Second I have trouble setting break points. When I set a break point and continue in gdb, it reports warning: Error removing breakpoint X.
Also, is there a programmatic API to trigger a break into GDB (asm("int3") enters JDB)?
Regards, Daniel
[init -> gdb_monitor] Remote debugging using /dev/terminal [init -> gdb_monitor] Memory model: no memory at address 1009164 [init -> gdb_monitor] Memory model: no memory at address 1009165 [init -> gdb_monitor] Memory model: no memory at address 1009166 ... REPEAT MANY TIMES [init -> gdb_monitor] Memory model: no memory at address 1000160 [init -> gdb_monitor] Memory model: no memory at address 1000161 [init -> gdb_monitor] Memory model: no memory at address 1000162 [init -> gdb_monitor] Memory model: no memory at address 1000163 [init -> gdb_monitor] Memory model: no memory at address 1000164 [init -> gdb_monitor] Memory model: no memory at address 1000161 [init -> gdb_monitor] (attempted to write 0) [init -> gdb_monitor] linux_resume_one_lwp(step = 0, signal = 0) [init -> gdb_monitor] genode_store_registers() - not yet implemented [init -> gdb_monitor] genode_wait_for_signal_or_gdb_interrupt [init -> gdb_monitor -> thread-migration] Starting ldso ... [init -> gdb_monitor] received signal for lwpid 1 [init -> gdb_monitor] linux_resume_one_lwp(step = 1, signal = 0) [init -> gdb_monitor] genode_store_registers() - not yet implemented [init -> gdb_monitor] genode_wait_for_signal_or_gdb_interrupt [init -> gdb_monitor] received signal for lwpid 1 [init -> gdb_monitor] linux_resume_one_lwp(step = 0, signal = 0) [init -> gdb_monitor] genode_store_registers() - not yet implemented [init -> gdb_monitor] genode_wait_for_signal_or_gdb_interrupt [init -> gdb_monitor -> thread-migration] Starting application ... environ: 85004 [init -> gdb_monitor -> thread-migration] ==THREAD MIGRATION EXAMPLE=============== [init -> gdb_monitor -> thread-migration] Creating thread [0] [init -> gdb_monitor] add_lwp(1, 2, 0) [init -> gdb_monitor -> thread-migration] Creating thread [1] [init -> gdb_monitor] add_lwp(1, 3, 0) [init -> gdb_monitor -> thread-migration] Creating thread [2] [init -> gdb_monitor] received signal for lwpid 2 Quota exceeded! amount=4096, size=4096, consumed=4096 ??
---- GDB SIDE --- (gdb) target remote localhost:5555 Remote debugging using localhost:5555 Reading symbols from ld.lib.so...done. Loaded symbols for ld.lib.so 0x00055c50 in _start_ldso () from ld.lib.so (gdb) (gdb) break OmniOS::sleep Breakpoint 1 at 0x1000160: file /home/dwaddington/git/omnios/genode/base/../omnios/include/omnios/sleep.h, line 45. (gdb) c Continuing. warning: Error removing breakpoint 1
-- On 10/20/2011 04:38 AM, Norman Feske wrote:
Hi Daniel,
I am trying to use GDB. It works fine with test-gdb_monitor, but with my own program I run in to memory quota problems. I tried to fix it through the config file but it did not seem to help. Any clues?
...
Quota exceeded: gdb_monitor memory for slab: 4096 used quota: 2175192 ds_size: 2138112 sizeof(Ram_session_component): 216 quota_limit: 3862528 [init -> gdb_monitor] C++ runtime: Genode::Ram_session::Quota_exceeded [init -> gdb_monitor] void* abort(): abort called
this message tells me that GDB monitor runs out of RAM quota. This can be explained as follows: When started, GDB monitor passes almost all of its own RAM quota to the target process and keeps only a fixed amount for itself. However, the amount needed in practice is not known at this point because GDB monitor's memory consumption depends on the behaviour of the target.
For example, GDB monitor has to copy ROM dataspaces requested by the target to RAM dataspaces in order to be able to patch the text segments of shared libraries (which are obtained by the target via ROM sessions). The memory for holding the RAM copy is accounted to the GDB monitor. Consequently, if the target creates a lot of ROM sessions, GDB monitor's RAM quota might exceed. I expect that this is the case in your scenario.
As a quick fix, I'd suggest to increase the amount of quota that GDB monitor keeps for itself. You can do this by changing:
ports/src/app/gdb_monitor/main.cc (line 66)
Maybe we should think about making this value configurable via the config file?
Best regards Norman