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

On 18.01.2018 02:41, Adam Lackorzynski wrote:
> On Tue Jan 16, 2018 at 01:38:18 +0300, Valery V. Sedletski wrote:
>> 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.
> I can just guess but probably, as this is a whole OS running inside
> QEMU, the timer is running with wall clock time and thus triggers
> everytime you let it run, and thus the immediate transition to the kernel.
>   
>> 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.
> Again I can just guess but I'd hope that would be a feature of QEMU to
> intercept those breakpoints added by its GDB stub. If that does not
> work, hmm.
I thought, as it is QEMU's own GDB stub, it could be aware of the 
breakpoints added by GDB, but it seems, not. Also, I googled in this 
list, that I should try inserting a breakpoint with enter_kdebug(), to 
trigger in JDB. Then when it stops, set a breakpoint in GDB, then "g" in 
JDB. Yes, would be a good idea.
>> 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 first try should be to disable the timer when you're at the point to
> debug. I'm not sure which platform you're on but maybe you could just
> disable the timer (i.e. clear the enable bit in the timer's control
> register).
I'm using i586 arch, Fiasco is configured to use the PIT timer for 
scheduling. Yes, will try disabling the timer, a good idea. I could try 
doing so in JDB, (via input/output to/from port command). At 
Stackoverflow, I also saw an idea to set a breakpoint at the exit from 
scheduler, so I could "continue" to that point (that was suggested for 
Linux kernel case).
>   I was hoping that this would be possible from QEMU monitor,
> but doesn't seem to.
Yes, I don't see something related to timer in QEMU monitor, or in its 
command line options. I only see the "-clock" option, but it seems to be 
related to a host-side timer backend, not an emulated timer.
>   What could be working is to disable it after some
> amount of ticks, i.e. when you're sure you're in the right position. But
> that would need to hacking of Fiasco.
>   
So, I need to try disabling the timer while being at some point in the 
kernel?
>> 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?
> I'm not aware there's anything like this for L4Env.
>
>
> Adam
Thanks!
> _______________________________________________
> 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