AVR 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 | Percent Complete: | 50% |
Assigned to: | dmix | Open/Closed: | Open |
Release: | 1.8.0 | Fixed Release: | None |
Wed 28 Mar 2012 09:21:09 PM UTC, comment #5: |
Georg-Johann Lay <gjlayde> |
Sat 24 Mar 2012 09:16:02 PM UTC, comment #4:
The right thing is to rework PR51345, thus reopend:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51345#c6
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
|
Dmitry Xmelkov <dmix>![]() ![]() |
Thu 09 Feb 2012 09:22:27 PM UTC, comment #1:
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 */
avr25 is split into:
avr25 /* 16-bit SP targets */
avr-gcc will pick the right multilib version depending on -mmcu=MCU and -mtiny-stack command line options as follows:
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
avr2/tiny-stack
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> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
"Abusing -mtiny-stack as multilib option" is filed as
http://gcc.gnu.org/PR52737
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:
.;
avr25;@mmcu=avr25
avr3;@mmcu=avr3
avr31;@mmcu=avr31
avr35;@mmcu=avr35
avr4;@mmcu=avr4
avr5;@mmcu=avr5
avr51;@mmcu=avr51
avr6;@mmcu=avr6
avrxmega2;@mmcu=avrxmega2
avrxmega4;@mmcu=avrxmega4
avrxmega5;@mmcu=avrxmega5
avrxmega6;@mmcu=avrxmega6
avrxmega7;@mmcu=avrxmega7
tiny-stack;@msp8
avr25/tiny-stack;@mmcu=avr25@msp8
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.