Debugger Design

[piyushpandey]

Hi Guys

I am studying about debugger , how they works and other stuffs related to
that but I am not finding the right stuff so that I can design my own
debugger for all ARM based processors and microcontrollers.


So I want to know that any of you having idea about the debugger
functioning i.e. how it works and how it produces the entire picture of all
functioning of the internals of a microcontroller etc. can please describe
me this.

Also if there is any relevant matter regarding this available anywhere on
the internet or personally can you please share it with me.


Thanks

---------------------------------------
Posted through http://www.EmbeddedRelated.com

[David Brown]

On 06/11/2012 06:49, piyushpandey wrote:
> Hi Guys
>
> I am studying about debugger , how they works and other stuffs related to
> that but I am not finding the right stuff so that I can design my own
> debugger for all ARM based processors and microcontrollers.
>
>
> So I want to know that any of you having idea about the debugger
> functioning i.e. how it works and how it produces the entire picture of all
> functioning of the internals of a microcontroller etc. can please describe
> me this.
>
> Also if there is any relevant matter regarding this available anywhere on
> the internet or personally can you please share it with me.
>

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.

[Boudewijn Dijkstra]

Op Tue, 06 Nov 2012 06:49:13 +0100 schreef piyushpandey
<21398@embeddedrelated>:

> I am studying about debugger , how they works and other stuffs related to
> that but I am not finding the right stuff so that I can design my own
> debugger for all ARM based processors and microcontrollers.

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?

> So I want to know that any of you having idea about the debugger
> functioning i.e. how it works and how it produces the entire picture of
> all functioning of the internals of a microcontroller etc. can please
> describe me this.

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

> Also if there is any relevant matter regarding this available anywhere on
> the internet or personally can you please share it with me.

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


--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/

[Zhu Feng]

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.

[Andrew Smallshaw]

On 2012-11-06, piyushpandey <21398@embeddedrelated> wrote:
>
> I am studying about debugger , how they works and other stuffs related to
> that but I am not finding the right stuff so that I can design my own
> debugger for all ARM based processors and microcontrollers.
>
> So I want to know that any of you having idea about the debugger
> functioning i.e. how it works and how it produces the entire picture of all
> functioning of the internals of a microcontroller etc. can please describe
> me this.

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.

--
Andrew Smallshaw
and...@sdf.lonestar.org

[upsid...@downunder.com]

On Tue, 6 Nov 2012 19:44:32 +0000 (UTC), Andrew Smallshaw
<and...@sdf.lonestar.org> wrote:

>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.

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.