Debugging TORO with BOCHS and GDB

In the following lines I'll tray to explain how debug Toro using bochs+gdb. I often used qemu instance of bochs but the latest days I figured out some rare behaviors so I replaced qemu for bochs with good results. 

Before to start we have to compile bochs for such purpose, after download the source run the next command in order to compile it:

> ./configure --enable-cpu-level=6 --enable-all-optimizations --enable-x86-64 --enable-pci --enable-vmx --enable-disasm --enable-debugger-gui --enable-logging --enable-fpu --enable-3dnow --enable-sb16=dummy --enable-cdrom --enable-x86-debugger --enable-iodebug --disable-plugins --disable-docbook --enable-gdb-stub     

> make install

It is not possible to enable the smp support and gdb stub at the same time. If the compilation was right we'll be able to run bochs with gdb support.

Now It is needed to compile the toro application within the debug symbols, if there're any old .o or .ppu file they must be deleted because they don't have symbols information. We should execute in the toro source directory the next commands:

> fpc ToroHello.pas -g -oToroHello -Fu../rtl/ -Fu../rtl/drivers

> ./build 4 ToroHello boot.o ToroHello.img

This procedure is for ToroHello.pas but it's the same for other toro's app.

So far, we've the bochs and the Toro's image, now we have to build the .bochsrc file and launch bochs.  The following lines may be useful:

megs: 32

ata0-master: type=disk, path="ToroHello.img"

boot: c

log: bochsout.txt

gdbstub: enabled=1

Check that we've indeed to enable the gdbstub in the bochs' source file.

The next step is to run bochs and then GDB:

> bochs

> gdb ToroHello

If we run gdb in the toro/test directory .gdbinit will be used, otherwise we have to connect to bochs manually as follow:

> (gdb) target remote localhost:1234 

If everything goes well we are able to set breakpoints and uses all the tools of gdb. For instance we could do:

> (gdb) b KERNELSTART

> (gdb) c

In the first line a breakpoint is set at KERNELSTART and then the virtual machine continues until comes back when the breakpoint is reached.

Many commands could be usefull in this point like n, for running line by line, step for stepping into, info registers and soon on.

There're a lot of information that we can get at this point but that's for another tutorial ;)

Matias E. Vara

www.torokernel.org

Toro's article in Microelectronic Congress 2012

Here it's the link to the article accepted by Microelectronic Congress 2012, its title is "Memory module designing for embedded purpose". It's about Toro Kernel memory module and it deals with the improvements did when an Operating System runs in a dedicated environment like embedded systems

In this opportunity the congress will be in the city of Rosario, Argentina. Unfortunately, this time I'll not be able to show the article as the last year. 

Again, the article is in spanish agreed with the congress' rules. 

Matias E. Vara
www.torokernel.org

Slides about migration threading in TORO

Here, I left a few slides about migration procedure in TORO kernel, I made a brief comparation with Linux mechanism. Also, I told a few lines about the migration in a real time environment.
Enjoy!

Matias E. Vara
www.torokernel.org

Git workflow for Toro

"Git workflow" is very known subject, It is possible find thousands documents talking about and with enough information that it makes unnecessary write other tutorial. Anyway, when I have to do any change in Toro's source, I do not follow any patter and I just make the changes and commit them. 

In order to make cleaner this procedure I decide to write a kind of  "git protocol" to be follow every time that I make a change on Toro.

I figured out how important is to be clear when we change the source, moreover if the project is huge and every little modification can become it unstable. It helps for understand the design and also for finding faster a possible bug. 

For implementing a new feature or fix a bug, we should start creating a new branch. It will keep our job independent of the master and we can mistake without care.

> git checkout -b new_branch

This will create a local branch and it will switch to it.

Makes the changes and then commits when you made enough changes, try to avoid very short commit that they aren't adding important information. 

> git commit -a 

Note about commit message:

"- Write in present

 - First line of the description is a short summary of the change:

      - If I’m fixing a bug, a small example of the bug I fixed or issue I was changing.

      - If I’m changing a feature, or adding a new one, why I think it the right choice and why I think it’s  

 acceptable or make that sort of change in the given part of the product cycle we are in."

For sharing your job before finish it, push the branch to the remote repo.

> git push -u origin new_branch

Then, in order to show all the branches either local or remote, first execute:
> git branch -a


And after that, to perform a local checkout run:
> git checkout -b new_branch origin/new_branch

It could be useful write a test in toro/tests/ in order to check the new feature and the stability of the kernel.

When you are sure about the changes, merge to master:

> git checkout master

> git merge --no-ff new_branch

A comment about --no-ff flags extracted from here:

"The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature"

Finally, we should remove the remote and local branch:

> git push origin :new_branch

> git branch -d new_branch


Matias E. Vara
www.torokernel.org

Toro debug with ECLIPSE

Hi everyone! I figured out that the server where I had the video about "TORO debug with ECLIPSE" is down, so I've uploaded it again. It shows the TORO Builder running on Windows 2003 x64. It is interesting how we can do "step by step" debugging and "set a breakpoint". Qemu is emulating a x86_64 arch.

Enjoy!   

Matias E. Vara
www.torokernel.org

Toro's article in Microelectronic Congress

Here it is the link to the article that I've shown at Microelectronic Congress 2011, Faculty of Engineering, University of La Plata, Argentina. The only thing is it is in spanish. It talks about TORO project and it shows a benchmarks that I made for my graduated project. Enjoy!

Matias E. Vara
www.torokernel.org

IOAPIC supported!

Until the latest TORO's source, I was using 8259 controller to catch interrupts, but the problem was all the interrupts were captured by the Boot Strap Processor (or core #0). This is not  agree with the dedicate hardware model.

In this way, I have started to use the IOAPIC instance of 8259 when TORO runs in a multicore environment. Thus, I can redirect the IRQ to the core where the hardware was dedicated. The dedication must be performed by the user.  

This is a new step toward a real multicore kernel.

Matias E. Vara

www.torokernel.org