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 <_valer...@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.
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
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
_______________________________________________
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
