l4/sys/syscalls.h: No such file or directory

Björn Döbel doebel at os.inf.tu-dresden.de
Wed Aug 20 19:53:02 CEST 2014

Hash: SHA1

On 20.08.2014 19:06, Valentin Hauner wrote:
> Hi,
> On 08/19/2014 02:55 PM, Björn Döbel wrote:
>> 2) Use Fiasco's thread primitives. For examples using this, you 
>> might want to grep for l4_thread_control in pkg/examples. There 
>> are a couple of examples using this.
> That worked, I used ex_utcb_ipc as a basis (located in 
> ./l4/pkg/examples/sys/utcb-ipc) and modified it. I replaced the 
> read/write operations in functions 'thread1' and 'thread2' with
> some simple test output with printf. However, after seeing the
> outputs 'Thread1 up' and 'Thread2 up', I'm getting the following
> errors:
>> L4Re[rm]: unhandled read page fault @18 pc=101d244 L4Re:
>> unhandled exception: pc=0x101d244
> These errors disappear by substituting 'l4re_env()->rm' in the
> thread control section of main.c with 'l4re_env()->main_thread',
> but then I don't get a 'Thread2 up' (logically).
> In another example that's very similiar to the above one, I'm
> getting these errors (with different 'pc'):
>> L4Re[rm]: unhandled read page fault @0 pc=0 L4Re: unhandled
>> exception: pc=0x0
> pc seems to stand for program counter, but how can I debug
> effectively here?

Right. The page fault message tells you the instruction pointer and
the page-faulting address. What I usually do in the first case
(PC=<some value not NULL>) is I try to figure out where in the program
this is using objdump. (If you are testing in Qemu, you might even try
attaching with GDB.)

In the second case (PC == 0) that won't work. This looks like someone
already performed a jmp/call to address 0. Here you will have to
figure out where things go wrong using printf()s. (Or GDB in the qemu

Does that help?

Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/


More information about the l4-hackers mailing list