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