Posts Tagged ‘gdb’

Summer is over, so put away the white pants and start submitting patches!

Thursday, September 10th, 2009

It’s been a while since my last update. What can I say… summer was nice.

But now, back to business! I’ve just committed some long overdue patches to the upstream GNU tools:

This gets us to booting the kernel, loading BusyBox, running some shell code and… crashing on the first fork. No problemo. Nothing a small matter of programming can’t fix. However, there are some other distractions…

Verilog is lots of fun! It looks like regular programming, but it feels more like building a kinetic sculpture.

There’s also the small matter of not having an interrupt controller! So there’s some work here to design an interrupt controller, implement it in verilog, simulate it qemu (and possibly the gdb sim), and port the kernel over to using it. This should be interesting…

Tags: , , , ,
Posted in moxie | View Comments

More hello world progress with uClibc/uClinux, and a GDB question.

Tuesday, August 18th, 2009

Tonight I got a hello world app to use uClibc’s puts() routine! This is a big deal because it’s the first time I’ve had system calls coming in from userland. I haven’t checked the changes in yet, because they’re a mess, but here’s a basic run-down of what I had to do…

  • First, uClibc had to be taught how to make system calls to the moxie uClinux kernel. This was straight forward, except I came across one surprise which I’ll describe below.
  • Next, I needed to add more files to my initfs. Specifically, I needed a /dev/console. Fortunately, the kernel build process makes this easy. I decided to use the “text file” approach to populating the initramfs as described in this document.
  • Finally, I had to create a tty device for my default console that spoke through the gdb simulator via software interrupts. Fortunately the ia64 port had a similar tty device for talking through one of HP’s simulators that I was able to mostly copy.

Once all this was done, I was able to build a standard Hello World app with moxie-uclinux-gcc, and it just worked!

What about the system call surprise? Despite what I read somewhere that said that Linux system calls had a maximum of 5 parameters — that’s not quite true. Some take 6 (are there any with 7? more?). This thwarted my attempt to get busybox running tonight, because it uses mmap, and mmap is one of those 6-argument system calls. There are a few ways to fix this. I think I’ll just hack the compiler to use 6 register arguments and see what that does to code size/performance.

If there are any GDB hackers reading this… I have one question for you… The kernel is loading and relocating my “init” program, then execve’ing it. When I run the kernel in gdb, it would be nice for gdb to load the debug info for init so I could see what it’s doing when I step into userland. Is there some way to do this manually?

Tags: ,
Posted in moxie | View Comments

Kernel update: device trees and kernel threads

Saturday, July 25th, 2009

I’ve spent a lot of time in airports/planes/hotels recently, which is good news for the moxie linux port. It runs about 6.5M instructions, booting up to the point where a couple of kernel threads are created. However, a few context switches later it all comes tumbling down. I didn’t have any of my kernel books with me, so I stopped hacking at that point rather than try to guess/decode how some of the internals are supposed to work.

My port is using a device tree to describe the system architecture. This makes it easier to build a single kernel image that can boot on multiple moxie implementations. There’s a good paper on this relatively new infrastructure here: http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf. If you’ve been following this project, you may recall that console I/O is implemented differently on the gdb and qemu simulators. For the gdb simulator we use a software interrupt instruction (swi) to escape to the simulator, but the qemu port uses a real simulated serial device. This means they need different console devices in the kernel to print boot messages. The device tree is a nice way to describe differences like this and have a single kernel image to boot in both environments.

Also, as predicted, I actually used moxie gdb’s reverse debugging feature to help debug my kernel bring-up. It was really useful a couple of times and has probably saved me the amount of effort required to implement it in the first place already!

The next week is going to be very busy for me, so I don’t expect to get much done. We’ll see…

Tags: , ,
Posted in moxie | View Comments

Reverse debugging!

Sunday, July 12th, 2009

A few weeks ago I happened to be in Palo Alto and met up with my friend and long-time GDB hacker Michael Snyder. He told me about a new feature in GDB called “process recording”. The basic idea is that when you tell GDB to enter into “record mode”, it records undo information for every instruction executed during the debug process. This lets you switch direction and start stepping through your code backwards in time! It’s a pretty amazing feature.

I was anxious to implement it for moxie, but only got around to it this weekend. The moxie ISA is relatively small, so it wasn’t much work. The patch looks something like this. And, as promised, you can now step forwards and backwards through moxie code. Reverse “continue” and “finish” also work. It’s going to be really handy when I get back to working the Linux kernel port.

Some GDB front-ends already have the controls in place for reverse debugging. Here’s a webinar showing reverse debugging on Eclipse. I mostly use Emacs as my moxie-elf-gdb frontend, but I’m not sure if it supports the reverse instructions nicely yet (of course you can “set exec-direction reverse” and use the normal step/next/continue commands).

Thanks to Micheal for pointing me at this new feature, and to Tea Water for implementing process recording in the first place.

UPDATE: Emacs support for reverse debugging should be arriving in 23.2. I’m not sure what the schedule for that is, but 23.1 is supposed to come out next week (July 22).

Tags:
Posted in moxie | View Comments

Quick update…

Wednesday, April 29th, 2009

A few quick MoxieDev updates…

  • The verilog output patch is in binutils
  • The moxie ports for binutils, newlib, libgloss and gdb are all upstream. Waiting on sim and gcc reviews.
  • The upstream qemu team have switched to git, so I’ve rebased MoxieDev’s qemu against this new repository.

Also, I’ve been reading the new OpenSPARC Internals book. It’s not quite what I was hoping it would be, but Chapter 7, OpenSPARC Design Verification Methodology, is fantastic. You can download it for free from this page.

I, however, bought this book from Amazon. And what’s interesting here is that it was printed by Bob Young‘s self-publishing startup, Lulu. It looks/smells/feels like a real book. I don’t know why I find this amazing, but I do. Bravo Bob!

Tags: , , ,
Posted in moxie | View Comments

Board Support Packages

Tuesday, March 17th, 2009

Today we’re introducing the notion of Board Support Packages (BSPs) to the moxie toolchain.

A BSP provides all of the configuration data and code requires to target a specific hardware platform. This mostly involves linker scripts, platform initialization code, and hardware abstraction support libraries.

Until recently the gdb sim was our only target platform. Now we also have qemu, which needs to use an alternate _write implementation in order to send output to a memory mapped UART. What we really need to do is to define a “qemu” BSP that targets the default “board” defined in qemu. This BSP will provide a support library with the UART version of _write, and the original gdb sim version will live in a “sim” BSP.

In the world of the GNU toolchain, BSPs live in libgloss. The libgloss tree now contains BSP specific linker scripts which you must use in order to pull in either of the BSP support libraries needed by newlib. So if you want to target qemu, you run…

$ moxie-elf-gcc -o hello.x hello.c -Tqemu.ld

..and if you want to target the gdb sim, you have to go…

$ moxie-elf-gcc -o hello.x hello.c -Tsim.ld

This will make more sense down the line as we add more target boards with different memory maps and peripherals.

Speaking of peripherals…. I’ve also added a Real Time Clock device to the qemu board definition which I’ll talk about in my next posting.

Tags: , ,
Posted in moxie | View Comments

Debugging with the moxie qemu simulator

Saturday, March 14th, 2009

I’ve finally cracked the gdb+qemu puzzle, so now we can debug code running on the qemu moxie simulator!

The last little gotcha was that the simulated $pc wasn’t being updated after single-stepping. This will get you nowhere fast! But it’s all fixed now, and here’s how it works…

$ qemu-system-moxie -s -S -kernel hello.x

This tells qemu to load our hello world program, hello.x. The “-s” option tells it to wait for a connection from GDB on port 1234. The -S option tells it to freeze on startup, and wait for a “continue” command from the debugger.

Now, in a different terminal, fire up moxie-elf-gdb on hello.x and connect to qemu like so:

(gdb) target remote localhost:1234

GDB and qemu should be talking now, and the debugger will report that the sim is waiting on __start, the entry point to our hello.x ELF file. Put a breakpoint on main, and hit ‘c’ to continue. You should be debugging as usual now. I normally run moxie-elf-gdb within emacs in order to get a nice UI, but invoking it from ddd or Eclipse should work just as well.

Everything has been committed MoxieDev. Now it’s time to enjoy this sunny day!

Tags: ,
Posted in moxie | View Comments