Re: L4/Fiasco kernel debugger (jdb) and step over command

On 29.12.2017 01:27, Adam Lackorzynski wrote:
> On Thu Dec 28, 2017 at 05:59:05 +0300, Valery V. Sedletski wrote:
>> On 28.12.2017 03:22, Adam Lackorzynski wrote:
>>> On Thu Dec 28, 2017 at 02:54:20 +0300, Valery V. Sedletski wrote:
>>>> On 28.12.2017 02:29, Adam Lackorzynski wrote:
>>>>> On Wed Dec 27, 2017 at 18:33:16 +0300, Valery V. Sedletski wrote:
>>>>>> On 27.12.2017 13:05, Matthias Lange wrote:
>>>>>>> Hi Valery,
>>>>>>>
>>>>>>>> On 26. Dec 2017, at 17:54, Valery V. Sedletski <[email protected]> wrote:
>>>>>>>>
>>>>>>>> Hi. I'm trying to debug my program with jdb. (I'm using the old L4/Fiasco / L4Env, not the current Fiasco.OC / L4Re). I enabled the permanent single step mode (with the S+ command) and a permanent show the Thread Control Block (with the t+ command) option. So, I was able to single-step with "g" command. Also, I found "jr" (go until return (ret or iret) is encountered) and "jb" (go until the next branch instruction, like jmp/call/int) commands, but they don't seem to work. When I enter them, I see only a single step to the next instruction. Are these two commands broken? How do I step over a "call"/"int" instruction?
>>>>>>> Fiasco/L4Env has been outdated for almost 10 years now and hasn’t been maintained since then. Sorry, but here we are unable to help you with your problem.
>>>>>> Yes, I know that  it's outdated now.
>>>>>>> Are there any reasons you chose Fiasco/L4Env over Fiasco.OC/L4Re?
>>>>>> My program is based on L4Env. I'm porting it to L4Re now. But first I need
>>>>>> to fix some bug and then continue porting it to L4Re. I think, someone could
>>>>>> remember some problems existed with L4/Fiasco kernel debugger. Also,
>>>>>> Fiasco.OC debugger may be very similar, so I expected someone could help me.
>>>>>> The problem is that I cannot find any commands similar to "step over"
>>>>>> command. There are "jb" (continue to the next branch instruction) and "jr"
>>>>>> (continue until next return instruction), but they don't seem to work. They
>>>>>> just do a single stepping. Does still anybody remember how could I step over
>>>>>> a "call" instruction? Maybe, in Fiasco.OC it's similar? Or, in Fiasco, it
>>>>>> was completely broken in the end?
>>>>> Indeed, jdb's functionality is still pretty similar here, including
>>>>> non-functionalities. Would you have a chance to run your code within
>>>>> QEMU and attach gdb to QEMU so that you could do your debugging?
>>>>>
>>>> So, it still does not work in jdb until now? Good, so debugging in GDB
>>>> inside QEMU still should work?
>>>> Is there any examples how to do GDB debugging (or, it is not specific to
>>>> L4/Fiasco or Fiasco.OC?)? I suspect that I need to link a GDB stub with my
>>>> program and connect to it with GDB via network somehow? Are there any
>>>> manuals somewhere?
>>> What I mean is rather attaching GDB to QEMU and using that to debug the
>>> whole L4 system. What maybe tricky here is to stop the system at the
>>> right point but breakpoints should do it here. QEMU options are
>>> -s and -S.
>>>
>>>
>>> Adam
>> So, I need to add the GDB stub to a microkernel somehow? Is this an option
>> somewhere in Fiasco configuration menu?
> No. The GDB stub is already there in QEMU, allowing to debug what is
> running inside QEMU. Just try it out :)
>
>
> Adam
Ok, didn't used remote debugging in QEMU, yet, but I had some experience 
with Bochs' built-in debugger. Sorry for asking such naive questions :) 
Now I tried to debug the Fiasco microkernel, together with L4Env and my 
application, in GDB, attaching to QEMU GDB stub. So, I attach GDB to 
QEMU, load a symbol table into GDB from my binary with "symbol-file" 
command, set a breakpoint to one of the symbols, then the breakpoint 
triggers successfully. But when I try to single-step my program with 
"next" or "step" commands, I suddenly switch into kernel, or another 
thread, due to context switch. Or even worse, instead of single-stepping 
my program, it continues its execution, as if I used the "continue" command.

Also, inserting "int 3" command into my program doesn't seem to work as 
well. I try sending two debug messages into the COM port, and insert an 
"int 3" instruction between them. I see both messages in the debug 
output, but "int 3" won't trigger (and no TRAP 3 occurs at all). I 
expected that the GDB stub has a corresponding trap handler, but it 
seems to be "iret" only.

So, are there any hints how could I single-step my program in GDB, 
avoiding task switches? Is it possible to debug my task/thread 
specifically, restricting the execution to a single task/thread? Is it 
possible to make "int 3" trigger?

I know that Genode (for example), has GDB monitor application, allowing 
to debug a single application, not the whole system. Is there such tool 
for L4Re/L4Env?

WBR,
valery
> _______________________________________________
> l4-hackers mailing list
> [email protected]
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers



_______________________________________________
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers