Re: [avr-gcc-list] avr-as and debugging symbols

[Joerg Wunsch]

"Mark P Anderson" <address@hidden> wrote:

> Avr-as appears to have a command line option called --gstabs that is
> supposed to include debugging information in the symbol table. This
> information is placed in the .stabs and associated assembler
> pseudo-ops. I'm able to use this feature to a certain extent, simple
> labels for variables and function names.

Sure, that's all it is supposed to provide.

> I was trying to create definitions similar to that which avr-gcc
> outputs of the form:

> .stabs "typedef char t:...",234,....

That's not a valid stabs syntax.  You write that you're using Linux.
Try "info stabs" there, that's the most complete stabs reference you
can find.  Keep in mind that there's nothing like a formal definition
for stabs, it's rather a historically grown debugging format.

Be warned though that this information is quite large and nothing you
can read and understand in a minute.  I didn't succeed in reading it
online but had to prepare a hardcopy first.

> What options does avr-gcc invoke avr-as with?

Just run it with -v to see them.

I've successfully inserted own .stabs instructions into assembler
sources that are assembled using --gstabs.  See here:

http://www.avr1.org/pipermail/avr-gcc-list/2003-April/004204.html

for an example.  No special options are needed.

> But when I use the standard tools to look for this avr-gcc debugging
> information I can't locate it. I've tried using:

> avr-objdump
> avr-readelf
> avr-nm

> Where does this information get placed?

In the .stab and .stabstr sections of the ELF output file.  Again, see
the stabs info document, what you're interested is the stabs usage in
object file sections.

avr-objdump -G can display you the raw stabs information.
avr-objdump -g converts the stabs (or any other recognized) debugging
information into pseudo-C code.

> Does avr-gcc/avr-as support debugging at all?

Sure, of course. :-)  avr-gdb has no problems reading the ELF/stabs
file.

> I need this information because I am building an AVR simulator and
> symbolic debugger to run under Linux since I can't get AVR Studio to
> behave.

This sentence is the main reason why i asked you to move this
discussion from avrfreaks to this mailing list.  Thank you for coming
here, i feel a lot more comfortable handling a mailing list using
Emacs than using the crappy forms editor of a Web browser.  Also,
there are a number of people here who might be interested in
discussing this issue.

First, the GNU binutils already contain a sophisticated parser for
stabs.  Even though it looks like a lot of work to understand how it
is working (many of the internal details of GNU binutils aren't
documented all that well), IMHO using it will save you a lot of work.

Second, you should be aware that there's already a usable debugger,
GDB.  It can read all this stuff, and if you're really going to write
your own, you'll have to spend a lot of effort to beat GDB
feature-wise.  The plain raw command-line UI of GDB might not be what
everbody loves, but there are GUI frontends for it already as well,
and in the course of writing your own debugger, you certainly won't be
able to avoid using GDB (as the host system's debugger) to debug your
tool anyway. ;-)  avr-gdb is the common name of the binary when being
configured and installed for an AVR target, but in the end, it's the
same GDB as your host system's (i. e. Linux') debugger.

Also, there are rumours that Atmel itself might switch to ELF some
day, and my gut feeling says me that they won't use stabs debugging
then, but more likely DWARF2 debugging.  That's probably the day when
the GNU toolchain has to use DWARF2 as well, which should be no big
deal given that other architectures/systems are already using it.  (My
native FreeBSD gcc/binutils/GDB has recently switched from ELF/stabs
to ELF/DWARF2, so i figure all that's needed must already be there in
the GNU source code.)  If you're going to write your own stabs parser,
you might have to start over again at this point, and write your own
DWARF2 parser...

So what's missing?  The weak point is still good simulation support.
There's simulavr (http://savannah.nongnu.org/projects/simulavr) which
is basically a working AVR CPU simulator but misses a lot of IO
features.  So far, all it can do is simulating the parallel port IO of
the standard ports but not much more.  However, i know that some
people are currently working on improving this situation, or intend to
work on it, or have already done quite a bit of work in this
direction.  So that's probably where you should start (IMO).

simulavr connects as a backend to GDB.  The other possible backend is
avarice which is the glue between GDB and the JTAG ICE box.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/