Re: [avr-libc-dev] AVR Elf Processing

[Joerg Wunsch]

[Torleif on Cc for some of the questions below.]

As Colin O'Flynn wrote:

> > The following bugs can be fixed by others:
> > -Layout of bitfields in the gcc dwarf debug output.
> > -Adding support for dwarf callstack information for AVR gcc

I have no idea about these.  Ted?

> > -Adding support for multiple memoryspaces in gcc.
> >   (I think this is work in progress?)

A discussion about this had been started by Svein (forgot his last
name) on the avr-gcc list recently.  The idea was to use a standard
proposal for extending C towards understanding memory regions as the
base for the implementation.  My guess (rather: fear) is that while
this is worthwhile, it'll become a major project to integrate into
GCC.

> > -Adding c++ support to avr-libc

The Atmel document lists a few things here:

* c++ support:

 There has been made no effort to support c++ in the new parser
 component.

   - There is no libstdc++ for avr-gcc.

   - operators new and delete are not implemented.

   - Some header files that come with avr-libc are not c++ safe.

   - Exceptions are not supported. They must be turned off using
     -fno-exceptions.

#1 won't happen anytime soon.  libstdc++ is far too huge to be useful
in its entirety.  There has been a discussion about a small support
library for C++ though.  Also, GPL or LGPL is most likely not
desirable for many embedded system programmers, so a GPL-free version
would be almost required.

#2: this shouldn't be too much work, and only requires a motivated
developer.  After all, malloc() and free() are already there (I've got
an extension in the pipeline for realloc(), but that's not yet
thoroughly tested, thus not in the mainstream sources yet).  I might
think about implementing new and delete myself, but it's got low
priority for me.

#3: I'd like to know which are these, they definately deserve to be
fixed.  Torleif, could I convince you to file a bug report for them
(on savannah.nongnu.org's Web interface)?

#4: IIRC, exceptions are turned off by default when configuring GCC
for the AVR; at least that used to be the case at some point in the
past.  Handling exceptions not only vastly bloats the generated code,
but also requires a couple of exception handler stubs that are part of
libstdc++ which we don't have.  Of course, should the idea of the
small libsuppc++ materialize, and someone knowledgable contribute
these helper functions there, this might get us the option for
exceptions, too, albeit I'm afraid they won't make any sense at all
for target MCUs smaller than an ATmega128.

Anyway, I don't see any of the above as show-stoppers for handling
C++.  #3 could easily be fixed, #2 being perhaps the next important
item on the list.  #4 is neglicible.  Simple classes, ineritance
etc. is supposed to work already well enough right now.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/