Re: [avr-libc-dev] [RFC] sections stub patch

[Joerg Wunsch]

As Theodore A. Roth wrote:

> :) It is both, initializing .data and initializing .bss.  In Unix-like
> :) targets, .data is normally initialized by the OS directly from the
> :) executable file.  Since this is impossible in an MCU environment,
> :) avr-gcc instead takes care of appending the .data variables after
> :) ..text in the flash ROM image.  .init4 then defines the function
> :) weakly() which takes care of copying the contents of .data from the
> :) flash to SRAM.
> 
> That's what I thought was happening. You mind if I just move the above
> into the dox?

Please do.  You might also mention that avr-size, coming from a Unix
background, doesn't account the .data initialization space to the .text
section, so in order to know how much flash the final program will
consume, one needs to add the values for both, .text and .data (but
not .bss), while the amount of pre-allocated SRAM is the sum of .data
and .bss.

> so .initN is 0 -> 9 and .finiN is 9 -> 0.

Yep.

> How does the .ctors and .dtors section work with .init6/.fini6 then?

Well, i tried hard to get a simple C++ file compiled...  It always
stumples across an undefined reference to __gxx_personality_sj0 which
it apparently expects to be a library-supplied global variable.  Hmm.
The value is copied over to the stack of main(), but never used.  I
wonder what it's good for.  If i declare an int variable in my program
with that name, it at least compiles. ;-)

As soon as there's at least one of .ctors or .dtors non-empty, .init6
requests the inclusion of __do_global_ctors(), and .fini6 the
inclusion of __do_global_dtors().

I've been surprised that even a /very/ simple C++ file eats up almost
2 KB of flash. :-(  A lot of the bloat accounts to calls to various
_Unwind_XXX functions, the remainder is regular library stuff
(including those functions that were called by my test class).

> One more question: Is it possible to have multiple functions assigned into
> the same .initN section? I see this in a map file:

Btw., they are not actual functions, just code pieces given a name.  In
particular, there's no return statement at the end, so it's merely code
pieces assembled into sequence by the linker.

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