Debugger Design

That's a rather broad question. Have you actually done any research yourself here, or are you just hoping someone else will do all the work and hand you it on a plate?

Fortunately for you, someone has!

Look up the OpenOCD project.

Op Tue, 06 Nov 2012 06:49:13 +0100 schreef piyushpandey :

What kind of debugger are we talking about here? E.g. which environments do you want to support in terms of:

• target interfaces;

• host interfaces;

• host operating systems;

• target operating systems;

• target programming languages;

• debugging features: - flash breakpoints, - power debug, - profiling, - program trace?

I have an idea. Mostly from reading manuals and using existing debuggers. Perhaps you should do that too.

That is quite a lot of material, perhaps you should narrow your question first.

From reading your post, I think you don't know enough to even program an ARM, let alone design and develop a debugger for one.

I think you need to do some study.

As others have noted this is an impossibly broad area and one that will inevitably involve study. NO ONE here could simply sit down and write a practical debugger for a real world system of the top of their heads - that includes the authors of various development tools that populate this group. At the very least they'll need to read up on countless specifics of particular implementations.

It seems to me rather you need a general plan of attack. It's not something I've ever done before (at least not for a system that actually exists) but with at least some understanding of systems programming my initial suggestions would be:

Phase 1

Read up on linkers and object file formats. Linkers & Loaders by John Levine is probably still the best book on the subject and I'd make that the first port of call. Keep it fairly general at this point, you don't want to be obssessing over the quirks of your particular architecture and operating system without a big picture understanding of what is going on.

Read up on ARM architecture. At the very least you need to be a reasonably fluent assembly programmer. The ARM ARM and Steve Furber's book (forget its name) would be good things to read. A good guide to a specific chip wouldn't be a bad idea to put things into context either. I have the technical reference to the StrongARM SA-110 somewhere around here, which although it is fairly dated now I'm sure would still be a treasure trove of useful information.

Phase 2

Start making everything more specific - read up on the linking specification of whatever system you are using (e.g. ELF or whatever). See what there is in operating system support for whatever is hosting your application. Pay particular attention to memory management facilities. It's difficult to be very particular here since it is inherently specific to what you choose to implement.

Phase 3

Then and only then start even outline design of your debugger before writing it. At this point you will no doubt have a hundred more questions but they will be much more specific and concrete so people will be able to help you, and they will be much more willing to help if you can show you done the groundwork of phases 1 & 2. Something like a debugger is difficult due there being so much in the way of low level nitty-gritty details rather than inherent complexity. If I had to take a wild stab in the dark I'd guesstimate it at around 500 hours work for something of reasonable functionality IF you have done the earlier groundwork properly. If you haven't multiply that figure by ten at best or forget the whole idea now at worst.

A bottom up approach would be to write a disassembler that converts an absolute program image to assembly instructions. This is pretty simple, but often not very useful, since all references would be numeric.

However, relocatable object files contain a lot of useful information. At least there are all external symbolic references and global symbol definitions that could be displayed in the disassembly listing. Some compilers even output some local symbols that might be very useful.

In the best case, there might be tags (as source line numbers) in the compiler output that might help to match source lines with machine instructions.

This might also help building a symbol table of variables.

Once you master these things, it is time to think about breakpoints and single stepping and more advances issues.