GDB debugging

[Daniel Waddington]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20111020/3e7d0587/attachment.html>