bugAVR C Runtime Library - Bugs: bug #35407, Missing multilib versions for...


You are not allowed to post comments on this tracker with your current authentication level.

bug #35407: Missing multilib versions for tiny-stack targets

Submitter:  Georg-Johann Lay <gjlayde>
Submitted:  Mon 30 Jan 2012 07:19:29 PM UTC
Category:  Feature Request Severity:  3 - Normal
Priority:  9 - Immediate Item Group:  Build system
Status:  In Progress Assigned to:  dmix
Percent Complete:  50% Open/Closed:  Open
Release:  1.8.0 Fixed Release:  None

Wed 28 Mar 2012 09:21:09 PM UTC, comment #5: 

"Abusing -mtiny-stack as multilib option" is filed as


and fixed now.

As -mtiny-stack cannot be used to select multilib and not influence multilib selection at the same time, a new option -msp8 has been added to avr-gcc. -msp8 is only used internally and deliberately undocumented.

-msp8 is set/removed automatically by -mmcu=. The only two values for -mmcu that don't trigger set/remove of -msp8 are avr25 and avr2 (resp. no mmcu at all) because these are the only two mmcu for which -msp8 is not determined uniquely.

The multilib layout and naming is the same as in 4.7.0.
However, notice the new output of

$ avr-gcc -print-multi-lib

and the last two lines thereof:


As always, the preferred way to build multlibs to work with gcc, is to depict its multilib layout from -print-multi-lib.

If you still have any questions, please don't hesitate to ask.

Georg-Johann Lay <gjlayde>
Sat 24 Mar 2012 09:16:02 PM UTC, comment #4: 

> What will happen if a 16-bit SP target in avr2 resp.
> avr25 is compiled with -mtiny-stack?

> In that case the compiler assumes SP_H to be always zero.
> However, the startup code will initialize SP to RAMEND
> so that SP_H is 1.

Sorry for the noise.

The right thing is to rework PR51345, thus reopend:


As far as avr-libc is concerned, there are no more changes needed. At least from the gcc side:

-mtiny-stack should not pick ./avr2[5]/tiny-stack if SP is 16 bits wide.

This means that no startup code for 16-bit devices is needed in tiny-stack multilibs. Reworking PR31345 will have impact on how multilibs are selected, but not how they are built or layed out.

Georg-Johann Lay <gjlayde>
Sun 18 Mar 2012 08:01:49 PM UTC, comment #3: 

Thanks for the changes.

What will happen if a 16-bit SP target in avr2 resp. avr25 is compiled with -mtiny-stack?

In that case the compiler assumes SP_H to be always zero. However, the startup code will initialize SP to RAMEND so that SP_H is 1.

Shouln't SP be initialized to MIN (RAM_END, 0xff) for these devices?

Georg-Johann Lay <gjlayde>
Sun 11 Mar 2012 12:37:27 PM UTC, comment #2: 

Avr-libc revision 2291 builds and installs tiny-stack
targets OK.
At this moment it is not tested in details.

Dmitry Xmelkov <dmix>
Group administrator
Thu 09 Feb 2012 09:22:27 PM UTC, comment #1: 

> If no library is found, the default from avr2 is used

Please notice: If no directory avr25/tiny-stack is available and thus the default avr2 is used, the linker will report an error because he cannot find the crtxxx.o startup code.

As a consequence, this issue is a real problem rather than just an extension.

Example: Compile a minimal progam like "int main(){}" with

avr-gcc main.c -mmcu=attiny24a

ATtiny24A has a tiny stack and its expected multilib including startup code is therefore avr25/tiny-stack

You need avr-gcc 4.7 from sources later than 3.Jan 2012 (GCC SVN trunk r182797) so see the problem.

Georg-Johann Lay <gjlayde>
Mon 30 Jan 2012 07:19:29 PM UTC, original submission:  

avr-gcc-4.7 adds better support for targets with 8-bit stack pointer, see


The outcome of the support is that there are new multilib variants needed for targets with 8-bit SP:

avr2 is split into:

avr2             /* 16-bit SP targets */
avr2/tiny-stack  /* 8-bit SP targets */

avr25 is split into:

avr25             /* 16-bit SP targets */
avr25/tiny-stack  /* 8-bit SP targets */

avr-gcc will pick the right multilib version depending on -mmcu=MCU and -mtiny-stack command line options as follows:

  • If no 8-bit SP derivatives are available (e.g. for avr4) -mtiny-stack has no effect on multilib selection.

  • If the MCU has 8-bit SP, avr-gcc picks libraries from avr2*/tiny-stack

  • If the MCU has 16-bit SP and there are 8-bit SP devices available for the same architecture (i.e. avr2, avr25) then avr-gcc will pick libraries from avr2* per default and from avr2*/tiny-stack if command line option -mtiny-stack is on.

  • If no library is found, the default from avr2 is used.

If avr-libc does not provide such libraries, the last point implies code size increase for 8-bit SP devices in avr25 as default from avr2 (no MOVW, etc.) is used as fallback.

For a proper implementation, avr-libc should provide multilib variants for


For a quick fix, avr2*/tiny-stack can be a copy of avr2*.

Notice that you can provide avr2/tiny-stack and avr25/tiny-stack with older compiler versions, too. These libraries will be unused and increase the installation size, but they won't hurt or disturb the compiler.

Georg-Johann Lay <gjlayde>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by arcanum (Updated the item)
  • -email is unavailable- added by dmix (Posted a comment)
  • -email is unavailable- added by gjlayde (Submitted the item)

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-11-16 arcanum Priority5 - Normal 9 - Immediate
    2012-03-11 dmix StatusNone In Progress
        Percent Complete0% 50%
        Assigned toNone dmix

    Back to the top

    Powered by Savane 3.13-4e86.
    Corresponding source code