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

[Rolf Magnus]

On Friday 25 August 2006 07:03, Joerg Wunsch wrote:

> Rolf Magnus <address@hidden> wrote:
> > 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.
>
> Given that, you've demonstrated that you can quickly navigate there,
> and found as much information as one could find there at a quick
> glance.
>
> Seriously, none of the current avr-libc maintainers would have done
> that better than you.
>
> (libsupc++)
>
> > 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.
>
> These have been mainly disabled because of a lack of such library in
> our standard installation.

I thought so. 

> > Now I tried to compile the following program with that lib:
> >
> > int main()
> > {
> >     throw 3;
> > }
> >
> > but avr-size tells me:
> >
> > It produced 22 kBytes of code and 1.2 kBytes of data.
>
> That's bee the second reason to default it to not handling exceptions
> many years ago when I tried my own first C++ program.

Well, this is with sjlj exception handling. I now managed to compile it with 
the newer exception handling method, and (at least I think that was the 
reason) the executable size got reduced to 11k for both the exception test 
and the new/delete test. Still haven't tried if it actually works. I guess 
now it's time to activate my atmega128 board that I bought a while ago. 
Usually, I use smaller devices that don't even have 11k flash, except for the 
atmega168.

> Even worse, I seem to recall that just an empty main() already drags in the
> exception code unless explicitly disabled from the command-line. So later
> on, their defaults have been changed. 

Doesn't seem to be the case anymore:

int main() {}

Compiled for atmega128 with exceptions enabled:

section    size   addr
.text       220      0
.stab      1032      0
.stabstr     84      0
Total      1336

That's exactly the same I get with the stock avr-g++. I also tried it with a 
real program, and the sizes look reasonable. There is no overhead when 
enabling exceptions. So I guess the code only gets pulled in if something of 
it is actually used.

> > 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
>
> Is this with the exceptions still enabled? 

I'm getting the same values, no matter if with -fexceptions or 
with -fno-exceptions. Seems kind of strange that there is a .gcc_except_table 
even whithout exceptions, but I don't know what that table is for. 
Maybe -fno-exceptions isn't working as it should.

> > 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.
>
> Hmm, that's bad then.  new and delete really should use the same
> memory allocator.

Agreed.

> > Well, new and delete aren't much of a problem, as long as you keep
> > exceptions out of the picture.
>
> Agreed.  That's been my opinion as well some 5 years ago.  OTOH, if
> exceptions were at least possible (without being enabled by default),

Well, if their code is really only pulled in when they are used, they could 
even be enabled by default.

> people with large processors might find them valuable for development/
> debugging.  If the 20 KB shown are only something like an initial
> overhead for exceptions that doesn't grow proportional to the size of
> the source code, on an ATmega128 or ATmega1281 this might be bearable.

Someone would need to write a bigger program that uses exceptions to test 
that. ;-)

> At least, your libsupc++ has got the helper function that was
> otherwise missing to get the exceptions even to link correctly at all.
> When I tried that, it failed to link, and just to see what would
> happen (and how large it will become), I then went ahead and supplied
> a dummy for that exception helper.  That got me into the same ~ 20 KiB
> application size you're seeing.  I think the division between
> libstdc++ and libsupc++ didn't exist back then (it's probably still
> been on GCC 2.95), and the full libstdc++ didn't compile on the AVR
> target.

It doesn't now either, but I didn't really expect that. Large parts of it are 
not too useful anway. Nowadays, you can compile libstdc++ in non-hosted mode, 
which will actually give you only libsupc++.

> So the dirty work to be done would be to turn all this into some kind
> of patch for GCC so it would do your steps automatically when being
> compiled for C++.  If possible, I'd vote to disable exceptions by
> default still, but you then have to override that for compiling
> libsupc++, which again means to patch something...

I started with configuring and compiling libsupc++ separately. Yesterday, I 
found out how to enable it to compile as part of the gcc build, but I 
currently have exceptions enabled by default, so I don't know what happens 
when they are not. Currently, everything compiles, as long as you 
add --disable-hosted-libstdcxx to configure. I'm looking into finding out how 
to pass that automatically to libstdc++'s configure. Damn... the auto* stuff 
is haunting me again.