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?
Thanks in advance,
valery
Hi Valery,
On 26. Dec 2017, at 17:54, Valery V. Sedletski _valerius@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.
Are there any reasons you chose Fiasco/L4Env over Fiasco.OC/L4Re?
Best, Matthias.
Thanks in advance,
valery
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
On 27.12.2017 13:05, Matthias Lange wrote:
Hi Valery,
On 26. Dec 2017, at 17:54, Valery V. Sedletski _valerius@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?
Best, Matthias.
Thanks in advance,
valery
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
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@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?
Adam
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@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?
Adam
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
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@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
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@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?
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@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
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@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.
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 l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
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@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
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 _valerius@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
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 _valerius@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?
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@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Matthias Lange -
Valery V. Sedletski