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

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

Re: [avr-gcc-list] WinAVR, file XXX not found in symbol table, ignoring.


From: Joerg Wunsch
Subject: Re: [avr-gcc-list] WinAVR, file XXX not found in symbol table, ignoring...
Date: Wed, 9 Feb 2005 12:30:24 +0100 (MET)

"Preben Mikael Bohn" <address@hidden> wrote:

>> Huh, ELF file?  The above is from the COFF conversion.
>> Which file format are you really trying to use?
> 
> That was a typo, sorry... :-)

Errm, I didn't notice you've sent me a Cc.  Here's my private reply
again for the list:

As Preben Mikael Bohn wrote:

> Well, the only reason why I need it is that I already made a few
> assembler programs using avr-gcc; however they are easily ported to
> atmel's assembler format, and I guess most people are using this
> anyway...

Maybe those who only program in assembler.  If you want to mix it with
C code, you are stuck with the assembler that belongs to the C
toolchain.

> > Don't expect anyone else to do this on your behalf.

> I don't; I simply thought that when it works using C-source files,
> it would also work using asm-source files; apparently I was wrong...

Nope, think a minute about it: the debugging information for compiled
C code is generated by the compiler backend, and inserted into the
assembler code the compiler generates (by means of assembler pseudo
ops, .stab/.stabs/.stabn for ELF/stabs, something like .debug etc. pp.
for ELF/DWARF-2).  The assembler then only translates these pseudo ops
into the respective representation in the object file.

In contrast, if you want debugging information for an assembler file,
you wouldn't want to got that way, and write your .stabs or .debug
pseudo ops yourself. ;-)  As a courtesy to the user, the GNU assembler
supports the automatic generation of debugging instructions to be
placed into the object file (basically this can only be line number
and file name information, as there's nothing like variable location
or data type information in assembler sources, unless of course you
add this manually again).  This is done by the -gstabs or -gdwarf2
assembler options.

While this is known to work reasonably well for ELF/stabs (both, for
native ELF, e.g. in GDB, as well for the COFF converter, with the
couple of mentioned .stabs lines you gotta add to tell about the name
of your original source file), it seems to cause propblems for
DWARF-2, at least in connection with AVR Studio.  This could be the
fault of the GNU assembler, it could as well be a problem of AVR
Studio.

If *you* give up on tracking and debugging this, and anyone else
asking for it also gives up, it will simply never happen.

I'm personally only interested in debugging with GDB, so in case
debugging assembler sources doesn't work in GDB, I might really track
that down, and fix it.  For AVR Studio, someone else needs to do it.
Trust me, Torleif Sandnes is a reasonable guy who's interested in
fixing any existing problem in his part of AVR Studio (the ELF and
DWARF-2 parser), so if you've got a problem, try contacting him (by
their official support channel).  If he claims the generated DWARF-2
code from the GNU toolchain is wrong, please ask him to continue the
discussion on the avr-libc developers mailing list (where he is
subscribed to), and please do also participate in that discussion
yourself.  That will be the only chance to fix any imminent problem.

Remember, the DWARF-2 support in the GNU toolchain is nothing that has
ever been *designed* for the AVR target there, it's simply a
by-product of making DWARF-2 work for the mainstream GNU toolchain
target architectures (i386, amd64, ...).  Given this, it already works
surprisingly well.

-- 
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]