Use of gcc tools and VMLAB to develop assembler projects.
It seems that there is a problem with that approach (title), I
searched the internet and the only thing I found was more people with
the same problem.
I decided to give it a try, after all, C programs works fine. From
what I was able to see, avr-as was emitting the needed stabs records
when invoked with --gstabs. But a comparison with elf files coming
from C source reveled a slightly different order in the stabs records.
I tried to contact AMC tools, with no success. That is when I realized
the latest VMLAB release was actually out in 2005. Their forum seems
to be offline as well. So, I abandoned any hope to hear from them and
decided to try a work around to this stabs loading problem.
The only work around I was able to find so far, is to re-create the
exactly sequence of .stabs directives the C compiler uses. That in
turns would make your project file unreadable. So, the approach I am
taking is to use a simple filter that automatically add the stabs
directives, just before avr-as is invoked.
If you find some other solution let me know.
1 - Rename the project file from .S to .X
2 - Cut and past 5 lines of code in every .X file. (That is left as a
permanent part of the project, see example)
3 - Change the makefile template to add one more step to the build
process. That step will convert a .X file into a .S one using the
little utility attached (stabify.c)
Note that now, the makefile invokes avr-as without the -gstabs option !!
4 - Build application, and use VMLAB as usual.
The project source is now named with a .X extension. The example
attached reads like this:
The first line is to make emacs happy, the sixth line is to make
objcopy happy. Note the filename on .file, and .stabs is the .X one.
The "main" in the last line is critical, if you change it, change
stabify.c to match. (I tried to do it automatically, see commented out
code in stabify.c. But VMLAB got confused when several lines .stabs
"xxx:F(0,x)..." are present. This needs to be fixed for multiple files
projects, but should be easy to do)
In the same way when you develop a C program, you rarely see the
assembler, here you will develop over this .X file, and will rarely
see the .S file that avr-as parses.
At any moment you can rename the .X back to .S, and make it go through
avr-as, etc. You don't have to change any project sources. So, in the
eventuality that AMC fixes VMLAB, or you get tired of this non-sense,
you only need to rename the .X back to .S and undo the Makefile
This is my first avr project, so this work around was only tested with
this program. Expect a thousand of little details that I
oversight. At least it is a start point...
Another thing I should mention. I hate VMLAB running my makes, and
forcing me to run build before anything else can be done. That is why
I have 2 makefiles, a dummy one that I give to VMLAB, and the real one
I run in my linux shell before using VMLAB. You don't need to do the
This solution is working for me, I hope this is useful for other
people as well...