Debugging without GDB - stack print?

[Alexander Tormasov]

Thank you for information!
Anyway, it is sill not clear for me

IP addresses below 0x1000000 usually belong to ld.lib.so, which is loaded first, whereas additional shared libraries usually reside
above the application.

Now you can find the source code location of the page fault with

$ genode-x86-objdump -dSCl debug/ld-sel4.lib.so | less

With ld.lib.so and the application image, you can look up the location with the page fault address directly, but with other shared
libraries you would need to subtract the load address first.

I do not find any information about other libs used by my application. It is not printed in log, only init, init->timer and init->log_terminal:
virtual address layout of core:
 overall    [0000000000002000,0000000200000000)
 core image [0000000002000000,000000000362a000)
 ipc buffer [000000000362a000,000000000362b000)
 boot_info  [000000000362b000,000000000362d000)
 stack area [0000000040000000,0000000050000000)
...
[init -> timer]   0x40000000 .. 0x4fffffff: stack area
[init -> timer]   0x30000 .. 0x197fff: ld.lib.so
[init -> log_terminal]   0x40000000 .. 0x4fffffff: stack area
[init -> log_terminal]   0x30000 .. 0x197fff: ld.lib.so
[init] child "timer" announces service "Timer"
[init] child "log_terminal" announces service "Terminal"
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x10
no RM attachment (READ pf_addr=0x0 pf_ip=0xa95b1 from pager_object: pd='init -> test-go' thread='ep')
Warning: invalid signal-context capability
Warning: page-fault, pager_object: pd='init -> test-go' thread='ep' ip=0xa95b1 pf-addr=0x0

This is all what I have in log (by the way, same address for stack and ld.lib.so mean that this is different process and virtual address spaces?).

And, for fault address inside debug/ld-sel4.lib.so
 page fault IP address 0xa95b1
Objdump show hat first address inside is from 49440 - is it real address which will be in memory?
/genode/build/x86_64/debug/ld-sel4.lib.so:     file format elf64-x86-64


Disassembly of section .init:

0000000000049440 <_init>:
_init():
/genode/repos/base/src/lib/ldso/startup/startup.cc:36<http://startup.cc:36>
        void _init(void) __attribute__((used,section(".init")));

        void _init(void)
        {
                /* call static constructors */
                for(ld_hook *func = _lctors_end; func > _lctors_start + 1; (*--func)());
   49440:       48 8d 05 f9 ff ff ff    lea    -0x7(%rip),%rax        # 49440 <_init>
Does it mean that it exactly correspond (page fault IP address 0xa95b1) place below, or I should subtract something from it (not clear still for me exact list of modules in memory)?
...
/genode/repos/base/src/lib/base/thread.cc:51<http://thread.cc:51>
                Ram_allocator * const ram = env_stack_area_ram_allocator;
   a959f:       48 b8 88 07 00 00 00    movabs $0x788,%rax
   a95a6:       00 00 00
   a95a9:       49 8b 44 05 00          mov    0x0(%r13,%rax,1),%rax
   a95ae:       48 8b 30                mov    (%rax),%rsi
/genode/repos/base/src/lib/base/thread.cc:52<http://thread.cc:52>
                Ram_dataspace_capability const ds_cap = ram->alloc(ds_size);
   a95b1:       48 8b 06                mov    (%rsi),%rax
   a95b4:       4c 8b 40 10             mov    0x10(%rax),%r8
   a95b8:       4e 3b 04 29             cmp    (%rcx,%r13,1),%r8
   a95bc:       0f 85 5e 02 00 00       jne    a9820 <Genode::Stack::size(unsigned long)+0x330>
_ZN6Genode25Constrained_ram_allocator5allocEmNS_15Cache_attributeE():
/genode/repos/base/include/base/ram_allocator.h:89
                        Ram_quota_guard::Reservation ram (_ram_guard, Ram_quota{page_aligned_size});
   a95c2:       48 8b 5e 10             mov    0x10(%rsi),%rbx


I wonder if your test application really needs to be started with Noux though. If it doesn't need fork() or execve(), it would
probably be easier not to use Noux.

I suppose that some of emulation of generic libc implemented inside noux (like used inside libgo getpid/pthread/etc) - and this is the main reason why I try to link it.
May be I am wrong ?

Alexander

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20190826/88167450/attachment.html>