Re: [avr-gcc-list] Debugging assembly code

[Joerg Wunsch]

"Larry Barello" <address@hidden> wrote:

> 1. Can COFF format handle modules acquired from a library in a
> different directory from the working directory?

That's not a matter of COFF itself, it's merely up to the COFF
consumer (i. e., AVR Studio, VMLAB, etc.) to search in other
directories.  GDB provides this feature (the »dir« command), IMHO AVR
Studio doesn't provide it, i don't know about VMLAB.

COFF just transfers the filename.  Old AVR COFF (the one understood by
AVR Studio 3.x, and produced by all the known freeware tools) can only
handle filenames up to 14 characters anyway.

The new, AVR »extended« COFF format understood by AVR Studio 4.x
(recent versions) can handle long filenames (though unfortunately,
they implemented it differently than the rest of the world), so in
theory, it could supply an absolute path name.

> 2. Can COFF format even handle modules pulled from a library?

It doesn't care where the modules come from.

What it definately cannot handle though is debugging symbols from
included filenames.  So if you've got a .h file that somehow
contributes to your code (e. g. through an inlined function), you are
screwed.

Of course, it cannot handle a lot of other things...  You might as
well ask what COFF /can/ handle at all. :-) The answer is easy: any
debug information that has been considered 10 (or more) years ago.  So
that's mostly anything you can do with K&R style C.  Since COFF
debugging information is a completely closed format that can hardly
extended in any way, there is no chance to get other languages or even
more modern C language features supported (inline -> include files,
const or volatile modifiers).

> I think this used to work with the old nordic module
> format.

Except that this format could /only/ provide line number information,
nothing else.  No variable information, no type information.

> Is there a better forum for .coff issues?

alt.folklore.computers :-)

It's still not clear to me why they have chosen an object file format
when it was clear that this format has already been obsolete for
almost a decade when they started their project.  And in particular,
while most limitations of COFF aren't of much concern for the small
AVR architecture that doesn't have shared libs and doesn't need a
number of other more modern features, it's still not comprehensible to
me why they've also chosen that braindead COFF debugging information.
COFF can also be had with stabs debugging information, which is what
UNIX (where COFF originates from) has been using for years back in the
era when UNIX used COFF (which was at System V Release 3.x).  Unlike
COFF debugging, stabs debugging is at least extensible and still in
use today (though slowly being phased out by DWARF debugging, it
seems).

But well, at least Atmel seems to have realized all this as well, and
so they keep promising they'll support ELF some day...
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/