doebel at os.inf.tu-dresden.de
Thu Nov 13 10:12:51 CET 2014
-----BEGIN PGP SIGNED MESSAGE-----
>>> I only have a pc=115c7a8, but since i start from 0x01000000, i
>>> guess that right?
>>>> 115c7a8: e28cca13 add ip, ip, #77824 ;
>> No way. This instruction adds a constant to a register and does
>> not touch memory at all. Hence it won't raise a page fault. Did
>> you objdump your program for that?
> I'm not sure what you mean.
The error you are seeing is a page fault. Page faults happen, when you
access memory that is not mapped. For this you need to be executing an
instruction that actually accesses memory. The instruction you found
does not access memory.
> I'm not experienced with objdump, though. But i can't look at all
> Load & Store instructions, do i? Looking for pc=15c7a8 isn't the
> solution, neither, since it's not there. So, what would u recommend
> to look for?
We are looking for an instruction at address 0x15c7a8. Things I would
* If the instruction is not in your program (the one in the build
directory), is it maybe in another module that gets packed into
your bootstrap.elf image? You get a list of the packed modules
when you run make E=.. - the binaries should all be in your build
* At the time of the page fault you end up in the kernel debugger.
Use 'lp' to see the list of present threads. One of them will be
the one that is in the debugger now. It should be one of the
L4Re threads (those have names starting with # in the thread list).
Which other thread is currently blocking in IPC to the L4Re thread?
What is this thread's state (command 't<id>')? At what instruction
is the thread stuck? What binary belongs to this thread?
* Easy stuff: is your program even executing code in its main()
function already? How far does the program get before the page
> My problem again: The function foo() is only called at one place in
> the code. I have to comment some stuff out in foo() to make the
> program work. But even if i dont call foo() (it is useless for this
> test-case), the program fails at the same place. So, the fault
> can't be in foo().
Then there seems to be no need for debugging foo().
Btw., are you debugging this on real hardware or in an emulator, such
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the l4-hackers