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

[Adam Lackorzynski]

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 <_valerius at mail.ru> 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.

> 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 was hoping that this would be possible from QEMU monitor,
but doesn't seem to. 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.
 
> 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