Gcc Tools for AVR Studio

There is a new gcc distribution on the Atmel Website for avr
controller.

http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=9772

It contains avr-gcc 3.4.0 with Dwarf debug format support and an
Elf/Dwarf parser component for AVR Studio.

Has anybody experience with this distribution ?

Klaus

"Klaus Hummel" <skiron1@gmx.net> wrote in message
news:ef8d8dd2.0406170303.10223027@posting.google.com...
> There is a new gcc distribution on the Atmel Website for avr
> controller.
>
> http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=9772
>
> It contains avr-gcc 3.4.0 with Dwarf debug format support and an
> Elf/Dwarf parser component for AVR Studio.
>
> Has anybody experience with this distribution ?

I've just installed it. It looks very like the avr-gcc tools that have been
around for some time. I haven't tried it yet.

Leon

skiron1@gmx.net (Klaus Hummel) wrote in message news:<ef8d8dd2.0406170303.10223027@posting.google.com>...
> There is a new gcc distribution on the Atmel Website for avr
> controller.
> 
> http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=9772
> 
> It contains avr-gcc 3.4.0 with Dwarf debug format support and an
> Elf/Dwarf parser component for AVR Studio.
> 
> Has anybody experience with this distribution ?

No, but I'm sure the next release of WinAVR will be built with DWARF
support to support this beta release of AVR Studio.

E. Weddington wrote:
> skiron1@gmx.net (Klaus Hummel) wrote in message news:<ef8d8dd2.0406170303.10223027@posting.google.com>...
> 
>>There is a new gcc distribution on the Atmel Website for avr
>>controller.
>>
>>http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=9772
>>
>>It contains avr-gcc 3.4.0 with Dwarf debug format support and an
>>Elf/Dwarf parser component for AVR Studio.
>>
>>Has anybody experience with this distribution ?
> 
> 
> No, but I'm sure the next release of WinAVR will be built with DWARF
> support to support this beta release of AVR Studio.


Why another debugging format?  What was wrong with COFF?

Sometimes I get irritated by what seems to be just new formats for the 
sake of new formats.

Well, if there's a good reason I guess I'll settle down.


Good day!


-- 
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

Chris Carlen <crobc@bogus_field.earthlink.net> wrote:

> Why another debugging format?  What was wrong with COFF?

Quite a lot, actually, if you're talking about genuine COFF debug info
(as opposed to embedding .stabs debug info inside a separate section
of a COFF file).

For starters, COFF is quite completely useless as soon as you have
#include'd files that actually generate code, because it has no way of
specifying more than a single source file name per object file for the
line numbers in the debug info to refer to.  If you're even thinking
of using inline function, let alone C++, that one's an almost certain
showstopper.  Actually anything short of DWARF2 is considered unusable
for C++ debugging by the experts.

And then there are some rather silly limitations, e.g. to a maxiumum
of 64 Ki-lines of source code with debug information --- unlikely to
bite you on an AVR, yes, but still a rather nasty limit if you ever
hit it.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Hans-Bernhard Broeker wrote:
> Chris Carlen <crobc@bogus_field.earthlink.net> wrote:
> 
> 
>>Why another debugging format?  What was wrong with COFF?
> 
> 
> Quite a lot, actually, if you're talking about genuine COFF debug info
> (as opposed to embedding .stabs debug info inside a separate section
> of a COFF file).
> 
> For starters, COFF is quite completely useless as soon as you have
> #include'd files that actually generate code, because it has no way of
> specifying more than a single source file name per object file for the
> line numbers in the debug info to refer to.  If you're even thinking
> of using inline function, let alone C++, that one's an almost certain
> showstopper.  Actually anything short of DWARF2 is considered unusable
> for C++ debugging by the experts.
> 
> And then there are some rather silly limitations, e.g. to a maxiumum
> of 64 Ki-lines of source code with debug information --- unlikely to
> bite you on an AVR, yes, but still a rather nasty limit if you ever
> hit it.


Well, I see then!

Thanks for the explanation.

Good day!


-- 
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19