bugAVR C Runtime Library - Bugs: bug #28837, using PSTR with c++ produces...

 
 

bug #28837: using PSTR with c++ produces warnings

Submitted by:  Hose Bag <user>
Submitted on:  Sun 07 Feb 2010 11:01:18 PM UTC  
 
Category: HeaderSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: InvalidPercent Complete: 0%
Assigned to: Joerg Wunsch <joerg_wunsch>Open/Closed: Closed
Release: 1.6.2Fixed Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Sat 29 Oct 2011 01:04:02 PM UTC, comment #7:

I wasn't suggesting someone else do the backport, but I was wondering about my chances of success with applying the same patch you made for 4.6.2 to 4.3.3. Recompiling the source rpm shouldn't be too much of an issue.

What is the reason people are not upgrading to 4.6? 4.4 and 4.5 are not recommended (http://www.arduino.cc/playground/Learning/Linux).

Volker Kuhlmann <vok>
Sat 29 Oct 2011 11:44:38 AM UTC, comment #6:

> Backport the gcc fix :-)
> it looks like it could be quite a while before it becomes
> available by normal upgrade.


avr-gcc's PR34734 is fixed in 4.6.2 and GCC 4.6.2 is available, see http://gcc.gnu.org/gcc-4.6

Bugfixes in avr-gcc are not backported to all versions supported by GCC because of avr-gcc developer shortage. That is: Bugfixes are only backported from current development trunk (4.7 at the moment) to 4.6.

Even if there was a backport to 4.5, you would still have to get a 4.5.3 distribution or build it yourself, anyway, as it won't tunnel into your local installation by magic ;-)

Georg-Johann Lay <gjlayde>
Sat 29 Oct 2011 10:42:01 AM UTC, comment #5:

Thanks Jörg. Those warnings are getting quite irritating in eclipse when there are a lot of them!

My suggestion has one drawback: Specifying sections in local variables gives a warning too, so I'm not sure what to do. Backport the gcc fix :-) it looks like it could be quite a while before it becomes available by normal upgrade.

The alternative is to declare the progmem variable extern first and then define it, but that has the same local variable problem.

I don't see any point in changing the section name, looking at the linker script shows that pretty much as long as it start with .progmem it's much of a muchness. The only requirement is to separate variable that are const into a differently named section from those not const. No functional difference, it's only to avoid the linker error. Maybe there's another way, but I can't think of a way to deal with progmems declared in functions. :-(

Volker Kuhlmann <vok>
Sat 29 Oct 2011 08:23:16 AM UTC, comment #4:

As it's a GCC bug which has already been fixed there, and it only
produces a warning, I somewhat hesitate to add hacks in avr-libc for
that.

Would there be any point in moving all PSTR data (independent of the
GCC version) to .progmem.data?

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Sat 29 Oct 2011 04:36:20 AM UTC, comment #3:

May I suggest to change the definition of PROGMEM for the buggy gcc versions as per the attached patch?

See bug #34680 for PSTR()

(file #24236)

Volker Kuhlmann <vok>
Sat 29 Oct 2011 01:06:21 AM UTC, comment #2:

The approach of redefining PROGMEM to
#define PROGMEM attribute(( section(".progmem.data") ))
works, but is sensitive to storage class specification.

gives
error: string2 causes a section type conflict

Program memory is read-only flash memory so not using const is a bug. Unfortunately it seems avr-libc is pretty buggy here...

Volker Kuhlmann <vok>
Sun 07 Feb 2010 11:14:50 PM UTC, comment #1:

Sorry, this is not an avr-libc bug but a GCC one. It has
already been filed to GCC's bugzilla:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734

Until it's fixed, you have to just live with the warning.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Sun 07 Feb 2010 11:01:18 PM UTC, original submission:

warning: only initialized variables can be placed into program memory area

this seems to be a regressiong, because it happens with code, that compiled about a year ago (no idea which version, maybe ~2007) without these warnings.

this was discussed in the ML 2009/12: http://lists.gnu.org/archive/html/avr-gcc-list/2009-12/msg00016.html

locally redefining...
#undef PROGMEM
#define PROGMEM _attribute_(( section(".progmem.data") ))

#undef PSTR
#define PSTR(s) (_extension_({static prog_char __c[] PROGMEM = (s); &__c[0];}))
... seems to fix it.

what's the "correct" approach to handle this?

Hose Bag <user>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #24236:  pgmspace.h.diff added by vok (1KiB - text/x-patch - pgmspace.h 1.71 diff PROGMEM fix)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by gjlayde (Posted a comment)
  • -unavailable- added by vok (Posted a comment)
  • -unavailable- added by joerg_wunsch (Posted a comment)
  •  

    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
    Sat 29 Oct 2011 04:36:20 AM UTCvokAttached File-=>Added pgmspace.h.diff, #24236
    Sun 07 Feb 2010 11:14:50 PM UTCjoerg_wunschStatusNone=>Invalid
      Assigned toNone=>joerg_wunsch
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1