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

 
 

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

Submitted by:  Georg-Johann Lay <gjlayde>
Submitted on:  Mon 30 Jan 2012 07:19:29 PM UTC  
 
Category: Feature RequestSeverity: 3 - Normal
Priority: 9 - ImmediateItem Group: Build system
Status: In ProgressPercent Complete: 50%
Assigned to: Dmitry Xmelkov <dmix>Open/Closed: Open
Release: 1.8.0Fixed Release: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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

"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.

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:

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
targets OK.
At this moment it is not tested in details.

Dmitry Xmelkov <dmix>
Project AdministratorIn charge of this item.
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

http://gcc.gnu.org/PR51345

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

avr2/tiny-stack
avr25/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>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 16 Nov 2012 06:48:12 PM UTCarcanumPriority5 - Normal=>9 - Immediate
    Sun 11 Mar 2012 12:37:27 PM UTCdmixStatusNone=>In Progress
      Percent Complete0%=>50%
      Assigned toNone=>dmix

    Back to the top


    Powered by Savane 3.1-cleanup