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

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

Re: [avr-gcc-list] Re: [avr-chat] AVR-G++ (Was: more of the same ;))


From: Rolf Magnus
Subject: Re: [avr-gcc-list] Re: [avr-chat] AVR-G++ (Was: more of the same ;))
Date: Thu, 24 Aug 2006 01:54:57 +0200
User-agent: KMail/1.9.1

On Wednesday 23 August 2006 21:27, Joerg Wunsch wrote:

> Eric Weddington <address@hidden> wrote:
> > Note that we have been actively seeking a C++ maintainer for the
> > toolchain:
> >
> > https://savannah.nongnu.org/people/?group=avr-libc

Was that supposed to be some kind of hint? :)
Anyway, I'm pretty new to gcc and don't really have much of a clue about it. 
After all, my first look at its sources was two days ago.

> And Rolf even lives in my timezone. ;-)
>
> I know him from the mikrocontroller.net forums already...
>
> Yes, Rolf, you've got many good ideas.  I hope it would at least be
> possible to get libsupc++ (?) working on the AVR, so maybe we could
> install that one in place of libstdc++ then.

Hmm, I just tried to compile it, and to my surprise, it actually does compile 
in freestanding mode if you don't go with the avr-g++ default of disabling 
exceptions and rtti. Now I tried to compile the following program with that 
lib:

int main()
{
    throw 3;
}

but avr-size tells me:

section              size      addr
.data                1270   8388864
.text               22728         0
.bss                  524   8390134
.stab                7296         0
.stabstr            18171         0
.gcc_except_table      39   8390658
Total               50028

It produced 22 kBytes of code and 1.2 kBytes of data. And:

int main() 
{
    delete new int(5);
}

produces:

section              size      addr
.data                 386   8388864
.text               20454         0
.bss                  526   8389250
.stab                7296         0
.stabstr            18171         0
.gcc_except_table      39   8389776
Total               46872

It probably pulls in lots and lots of unneeded stuff. Dunno if it actually 
works or what operator new is using for memory allocation here. It doesn't 
seem to be avr-libc's malloc.

> As a stop-gap measure, perhaps we should patch GCC right now to rather
> use -lc than -lgcc then.  But no, that won't work very well either.
> The darn thing is that this library (and -lm) are always linked
> *prior* to any of the user libraries, and I think that's a bug.
> User-specified libraries should always take precedence.  If we use -lc
> as a replacement, and the user specifies one of the custom vfprintf
> libraries, the linker would find the standard vfprintf earlier, and
> use that one instead of what the user intented.  So abusing -lm might
> work, or maybe I should just create a libempty.a in the next release
> of avr-libc, and we patch GCC to use that one instead of libstdc++ by
> now.

I was about to suggest a library called libnull.a ;-)

> But in the long run, I agree, some kind of C++ library would be really
> a Good Thing.  At the very least, we could support real new and delete
> operators,

Well, new and delete aren't much of a problem, as long as you keep exceptions 
out of the picture.

> maybe even some kind of exceptions (they require a helper function in a
> library we currently don't have).  For sure, streams IO might make sense as
> well. 






reply via email to

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