Debugging without GDB - stack print?

[Christian Prochaska]

Hi Alexander,

On 26.08.19 11:18, Alexander Tormasov via users wrote:
> 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?).


core, init, timer, log_terminal, test-go, ... are different processes
with their individual address spaces. So it looks like the page fault
happened already before ld.lib.so could print the memory layout for
'[init -> test-go]'.


> 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
>

For ld.lib.so and test-go, the address corresponds exactly. So, the page
fault appears to occur at

Ram_dataspace_capability const ds_cap = ram->alloc(ds_size);

Maybe 'env_stack_area_ram_allocator' (thread.cc:51) has not been
initialized?


> 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 ?


I would try a simple "hello world" application without Noux first and
hope that libgo does not need fork, execve, wait or getpid for that.
pthreads should also work without Noux.

Christian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20190826/8d124cff/attachment.sig>