Re: using __func__ once increases _end (variable area size) by 446 bytes?

[Britton Kerin]

On Sat, Dec 19, 2020 at 10:40 AM Britton Kerin <britton.kerin@gmail.com> wrote:
>
> On Fri, Dec 18, 2020 at 11:27 PM Joerg Wunsch <j@uriah.heep.sax.de> wrote:
> >
> > As Britton Kerin wrote:
> >
> > > The function name is only 17 characters.  How can using __func__ cause
> > > such a dramatic increase in the variable area size?
> >
> > Well, the avr-libc list ist probably not necessarily the right place
> > to ask questions about the compiler itself. Anyway, please provide a
>
> Sorry you had the FAQ item that gave me a clue.  I was hoping there might
> be some known reason it does that.
>
> > compilable example so others could reproduce and analyze what you've
> > been observing.
>
> I'll try to isolate it more.  It doesn't cause that big size explosion
> for small test programs and I have no idea yet why it would do
> so when used in a large program.

So it looks like when __func__ is passed to printf() (including when passed
as the format string) the the names of most or all of the function in the
file containing the function end up in the variable space, even if they're
never called .  This doesn't happen when __func__ is just referenced, or
when it's passed to strncpy as the src.

But there seems to be a cure: the -fdata-sections avr-gcc option causes the
ELF file to end up with only the actually used __func__ names.

This might deserve a mention in the FAQ, and for that matter so might
-ffunction-sections.  The fact mentions sizes for different -o options, but
the effect of -ffunction-sections is likely to be much larger in many real
situations, and it seems that -fdata-sections can be significant as well
(if not exactly to program size but stack space).

Britton