Linux IO_MEM session

[Norman Feske]

Hi Johannes,

> I implemented this but when I try to attach the dataspace I get a
> segfault. I though this might be related to a wrong physical address for
> the file but the backtrace leaves me completely clueless.
> 
> 
>> #0  pseudo_end () at /media/sf_kernel/genode/repos/base-linux/src/lib/syscall/spec/x86_64/lx_syscall.S:29
>> #1  0x000000000109d7c1 in lx_futex (val=0, op=0, uaddr=<optimized out>) at /media/sf_kernel/genode/repos/base-linux/src/lib/syscall/linux_syscalls.h:350
>> #2  thread_stop_myself () at /media/sf_kernel/genode/repos/base-linux/src/include/base/internal/lock_helper.h:66
>> #3  Genode::Cancelable_lock::lock (this=this at ...551...=0x80ffae0) at /media/sf_kernel/genode/repos/base/src/lib/base/lock.cc:123
>> #4  0x00000000010b19c8 in Genode::Lock::lock (this=<optimized out>) at /media/sf_kernel/genode/repos/base/include/base/lock.h:33
>> #5  Genode::sleep_forever () at /media/sf_kernel/genode/repos/base/src/lib/base/sleep.cc:21
>> #6  0x0000000001065eb8 in Genode::Signal_receiver::block_for_signal (this=this at ...551...=0x64b4a70 <Genode::bootstrap_component()::startup+3472>)
>>     at /media/sf_kernel/genode/repos/base/src/core/signal_receiver.cc:49
>> #7  0x0000000001096a70 in Genode::Entrypoint::_process_incoming_signals (this=this at ...551...=0x64b3e40 <Genode::bootstrap_component()::startup+352>)
>>     at /media/sf_kernel/genode/repos/base/src/lib/base/entrypoint.cc:108
>> #8  0x000000000109772e in Genode::Entrypoint::Entrypoint (this=0x64b3e40 <Genode::bootstrap_component()::startup+352>, env=...)
>>     at /media/sf_kernel/genode/repos/base/src/lib/base/entrypoint.cc:329
>> #9  0x00000000010915ac in Genode::Startup::Startup (this=0x64b3ce0 <Genode::bootstrap_component()::startup>)
>>     at /media/sf_kernel/genode/repos/base/src/lib/base/component.cc:244
>> #10 Genode::bootstrap_component () at /media/sf_kernel/genode/repos/base/src/lib/base/component.cc:259
>> #11 0x00000000010cd016 in _main () at /media/sf_kernel/genode/repos/base/src/lib/startup/_main.cc:248
>> #12 0x0000000000000000 in ?? ()

are you sure that this is the backtrace of the faulting thread? It
doesn't look like it. To double-check, have you had a close look at the
instruction pointer within the faulting binary as reported by the
kernel's dmesg output?

As another question, did you first try to hand out an FD for a regular
file as I suggested in my last email? Just to rule out potential
problems with the FD obtained from your kernel module.

The 'rm.attach' - when executed on Linux - is just a process-local
operation. It comes down to an invocation of 'mmap' in
'region_map_mmap.cc'. Maybe it helps to instrument the code there? For
instrumentation at such a low level, I recommend using the 'raw'
function instead of 'log'. The 'raw' function directs the output
directly to the kernel - not to core's LOG service. You won't see the
component's name as log-message prefix, but rule out any interaction
with core by the instrumentation.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth