> "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.
Here's some output from "avr-gcc -S -g test.c" that shows
the syntax I was trying to assemble.
> 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.
I was able to insert .stabs information also, just not the way that
avr-gcc seems to be able to.
> > 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.
Again, I was able to do this but not for the avr-gcc information.
> > 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.
Yes, I want to avoid 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.
When I got the tar of avr-gcc I don't believe that avr-gdb was
part of it, at least it's not on my machine now. So I'll have
to go find and install it. I don't mind using the command line
version of gdb.
> 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...
I don't want to write anything that already exists. I know I can
use avr-objdump to print out the .stabs information if I need it.
> 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.
This is the subject that interests me the most. What I need
is a simulator/symbolic debugger that will have capabilities
equivalent to AVR Studio but really work. It have to run
under Linux w/o X on modest h/w, laptop, 100Mhz, 40MB RAM,
..., also no Microsoft OS.
I know of simulavr but when I last looked at it it was rather
primitive. I use gdb for other things and it would be fine,
it's just that I didn't know how to interface it with an AVR
simulator. So what you're telling me is that simulavr is the
place to start, it has some capability already, can interface
to gdb, and may possibly be under development.
My other ambition was to provide an ncurses gui so I could
have at least two windows up, one source code and the other
memory/register/io information displays. That's why I was
considering writing my own simulator. Actually writing the
instruction set simulator isn't all that difficult, its the
user interface that's a lot of work.
I'll check into simulavr and see how far along it is and how
it interfaces to gdb.
At the present time I don't need JTAG ICE although I do have
an ICE-200 that I don't use. Has anyone ever used this product
for anything? My applications are fairly simple at the moment
so I'm starting small. Plus I have no budget seeing that it's
a home activity for me and one of my children. I don't mind
writing software but then again I'd rather start where others
have left off or use what's available if it meets my needs.
I appreciate the support. I'll post my findings in a little
while. Any other ideas/comments?