Time For "Community Development" ML?
Hi Norman, What do you think of setting up a new "Community Development" mailing list, for discussion and coordination within the development community that doesn't need the attention of the core developers? We're probably already at the stage now where it would be helpful, but I think the "Year Of Sculpt" will generate much wider hobbyist interest than in the past, which could disrupt the S/N ratio of this list. (Eventually, an end-user oriented ML would probably be a good idea also, but that should be a year or more away.) Thanks! -- John J. Karcher devu...@alternateapproach.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Memory write tracing/logging of an application / Watchpoints in Genode/Fiasco.OC
Hi, > As you should be the parent of the traced component, you can intercept > the CPU session and remember all thread capabilities created by the > component. On a fault you iterate through all threads to select those > that are currently in a page fault. A good example for this is the GDB > monitor [1]. Ok, so far, so good, I could successfully get the threads within my target process and indeed access the correct instruction pointer. But the next problem is that Thread_state::unresolved_page_fault for me always 0 is, for all threads (I provoked a pagefault by detaching the dataspace), so I can't filter out the faulter(s). Do you have a clue? As long as I don't attach a dataspace at the corresponding address, it should indeed be an unresolved page fault, or am I wrong here? > Now you want to select from the remaining threads those > that are in a fault on your specific address. This can't be done with > the current Genode API, but an easy way to achieve it would be to expand > the Cpu_state [2] to deliver also the value of the ARM Data Fault > Address Register or DFAR when calling Cpu_thread_client::state (make > sure to update the dfar member in [4] as is done in [3]). Good. I'm using Fiasco.OC though, so I'll have to figure out how to do this there. Writing a custom kernel function making the assembler call copied from Genode just froze the VM, but I already asked the Fiasco.OC people for help. > Then, you would have to continue execution of > the thread. Unfortunately, this is normally done automatically by > Genodes Core when it sees a new mapping that matches the fault address. > You don't want to do such a mapping, but there is no explicit "resume > this faulter". So, you have might add such an RPC call [5] and its back > end [6] to the RM interface. This shouldn't be much invasive. At least this seems to work. > If there are further questions please do not hesitate to ask ;) That's very nice of you, thanks a lot for your help! Cheers, Josef -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Linux IO_MEM session
Hello Johannes, On Thu, Jan 25, 2018 at 11:25:20AM +0100, Johannes Kliemann wrote: > > _ds_cap = _ds_ep->manage(&_ds); Looking at the generic implementation we learn that it also needs a cast after the manage base/src/core/io_mem_session_component.cc:87: _ds_cap = static_cap_cast(_ds_ep->manage(&_ds)); For testing I adapted this to the current inheritance state in base-linux, which then compiles base-linux/src/core/io_mem_session_component.cc:72: _ds_cap = static_cap_cast(static_cap_cast(_ds_ep->manage(&_ds))); So, the implementation currently prevents to provide Io_mem_dataspace as easy as Dataspace because there's no hook to tell the generic parts that a Dataspace is in fact a Linux_dataspace because Io_mem_dataspace directly inherits Dataspace. Sounds twisted, but that's the reason in my opinion and we need to do some refactoring to make the Io_mem-related modules tweakable in this regard. Regards -- Christian Helmuth Genode Labs https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Linux IO_MEM session
Hi Norman, > just a shot in the dark: Have you called 'Rpc_entrypoint::manage(ds)' > for your dataspace object? Or to put the question differently: Is the > dataspace capability that you return in > 'Io_mem_session_component::dataspace()' valid inside core? If not, you > have most likely missed to associate your 'Dataspace_component' object > with core's entrypoint. I had this issue already in the first email where I tried to do exaclty this. I read through it again and my explanation wasn't clear. When I add > _ds_cap = _ds_ep->manage(&_ds); It fails to build with > In file included from > /.../genode/repos/base/include/dataspace/capability.h:17:0, > from /.../genode/repos/base/include/dataspace/client.h:17, > from > /.../genode/repos/base-linux/src/include/linux_dataspace/client.h:17, > from > /.../genode/repos/base-linux/src/core/io_mem_session_component.cc:15: > /.../genode/repos/base/include/base/capability.h: In instantiation of > ‘Genode::Untyped_capability Genode::Capability< > >::_check_compatibility(const Genode::Capability&) const > [with FROM_RPC_INTERFACE = Genode::Linux_dataspace; RPC_INTERFACE = > Genode::Io_mem_dataspace; Genode::Untyped_capability = > Genode::Native_capability]’: > /.../genode/repos/base/include/base/capability.h:153:49: required from > ‘Genode::Capability< >::Capability(const > Genode::Capability&) [with FROM_RPC_INTERFACE = > Genode::Linux_dataspace; RPC_INTERFACE = Genode::Io_mem_dataspace]’ > /.../genode/repos/base-linux/src/core/io_mem_session_component.cc:72:34: > required from here > /.../genode/repos/base/include/base/capability.h:134:24: error: cannot > convert ‘Genode::Linux_dataspace*’ to ‘Genode::Io_mem_dataspace*’ in > initialization > RPC_INTERFACE *to = from; I tried to circumvent this by trying different casts but I could not find an appropriate solution (fooling the compiler with typedefs is not one). When you said that opening the file and adding the file descriptor was enough I misinterpret that I don't need to call manage. > Could you point me to a branch where I can have look at the code and > reproduce the problem? I have a state on [1] that contains a test `run/io_mem` which tests that behaviour. I also have added a check to [2] so `attach` does not segfault but throws an `Invalid_dataspace` exception. In io_mem_session_component.cc I have already added (but commented out) the line to call manage which does not build yet. Thanks for your help and regards, Johannes [1]: https://github.com/jklmnn/genode/tree/ac59709d4af406125454180e5453f30184505a8d [2]: https://github.com/jklmnn/genode/blob/ac59709d4af406125454180e5453f30184505a8d/repos/base-linux/src/lib/base/region_map_mmap.cc#L190 [3]: https://github.com/jklmnn/genode/blob/ac59709d4af406125454180e5453f30184505a8d/repos/base-linux/src/core/io_mem_session_component.cc#L72 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: noux_bash failure
Hi,
On 23.01.2018 22:37, genode user wrote:
> I still cannot get sel4 to work properly. The qemu VM opens up and says
> "Booting Genode on seL4" but gets no further. On the terminal on the host
> I see this:
> [init -> timer] Error: IO_PORT-session creation failed (ram_quota=6K,
> cap_quota=2, io_port_base=64, io_port_size=4)
> [init -> timer] Error: __cxa_guard_abort called
> Kernel: Thread 'ep' died because of an uncaught exception
> [init -> timer] Error: Uncaught exception of type 'Genode::Service_denied'
> [init -> timer] Warning: abort called - thread: ep
> [init -> drivers -> platform_drv] Error: IO_PORT-session creation failed
> (ram_quota=6K, cap_quota=2, io_port_base=3320, io_port_size=4)
> [init -> drivers -> platform_drv] Error: __cxa_guard_abort called
> Kernel: Thread 'ep' died because of an uncaught exception
> [init -> drivers -> platform_drv] Error: Uncaught exception of type
> 'Genode::Service_denied'
> [init -> drivers -> platform_drv] Warning: abort called - thread: ep
> [init -> drivers] child "platform_drv" exited with exit value 1
>
> Any suggestions?
it seems to be a packaging problem of Genode/seL4. Re-building core
instead of using core from the package, as quick quirk, works for me on
x86_32:
--- a/repos/ports/run/noux_bash.run
+++ b/repos/ports/run/noux_bash.run
@@ -131,6 +131,7 @@ Hello world !!
}
-build_boot_image { }
+build { core }
+build_boot_image { core }
run_genode_until forever
--
Alexander Boettcher
Genode Labs
http://www.genode-labs.com - http://www.genode.org
Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
