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

On Thu Jan 18, 2018 at 08:47:52 +0300, Valery V. Sedletski wrote:
> 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?

Yes, basically. An easy way could be to disable the timer after some
amount of ticks, i.e. the number of ticks when you're at the point of
debugging. There should be timer-tick functions in the kernel that are
called periodically.


Adam

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