avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] VMLAB


From: Joerg Wunsch
Subject: Re: [avr-gcc-list] VMLAB
Date: Thu, 24 Apr 2003 16:46:31 +0200 (MET DST)

>I thought this was a generic problem with the old COF format:
>Libraries and source files from other directories were not included.
>It is the same with Studio.

VMLAB should have no problems with files located in different
directories, they're using another algorithm (they must be named in
the project file anyway, so as long as the filename given in the COFF
file matches one from the project file, they should find it).

However, i've got a suspicion what's the reason for this behaviour.
It's indeed related to one of these many stupidities of the COFF
debugging information.  Historical note: COFF's debugging info is
targeted to debug C code, so things like assembler, C++, FORTRAN,
Pascal, ... are not handled at all.  And, COFF has been designed by a
time when disk space was much more expensive than today.  For that
reason, line numbers are stored as two-byte values only.  In order to
not limit the range to source files with < 64 K lines only, the line
numbers are then stored relative to the current function (where the
function symbol has an absolute 32-bit base line number attached to
it).

Now, gas' --gstabs trick implicitly adds line number stabs entries for
each assembler source line.  (Normally, stabs entries are not
generated by the assembler but by the compiler only, and passed to the
assembler within .gstabs/.gstabn assembler pseudo ops.)  However, since
there are no function stabs entries that way, any tool translating the
stabs to COFF debugging information is at a loss here.

I think the situation could be handled by picking up the closest
non-stabs symbol, and synthesizing a function debugging symbol from
it.  However, that's a lot of effort.  It's probably more appropriate
to rather structure the assembler source in a way so it actually emits
function stabs entries.  This could e. g. be hidden from the user
inside something like a FUNCTION() macro.

I'll have a closer look at this soon.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]