bugAVR C Runtime Library - Bugs: bug #32945, Wrong PF implementation in pmstring

 
 

bug #32945: Wrong PF implementation in pmstring

Submitted by:  Thomas Kaiser <th_k>
Submitted on:  Tue 29 Mar 2011 06:05:42 PM UTC  
 
Category: LibrarySeverity: 5 - Blocker
Priority: 9 - ImmediateItem Group: libc code
Status: In ProgressPercent Complete: 50%
Assigned to: NoneOpen/Closed: Open
Release: 1.7.*Fixed 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 09 Oct 2013 01:08:19 PM UTC, comment #5:

RAMPZ address is hard-coded already (revision 2279) in case of building avr-libc. This resolves AVR_RAMPZ_ADDR definition error.

I have attached patch (restore-rampz.patch) to restore RAMPZ value for all xxx_PF() functions.

ChangeLog
2013-10-09 Pitchumani Sivanupandi <pitchumani.s@atmel.com>

Fix for bug #32945.

  • common/macros.inc: Save RAMPZ register if RAMPD is present.

Add LPM_R0_ZPLUS_FINI macro to restore RAMPZ if RAMPD exists.

  • libc/pmstring/memcmp_PF.S: Restore RAMPZ before return.
  • libc/pmstring/memcpy_PF.S: Same.
  • libc/pmstring/strcasecmp_PF.S: Same.
  • libc/pmstring/strcat_PF.S: Same.
  • libc/pmstring/strcmp_PF.S: Same.
  • libc/pmstring/strcpy_PF.S: Same.
  • libc/pmstring/strlcat_PF.S: Same.
  • libc/pmstring/strlcpy_PF.S: Same.
  • libc/pmstring/strlen_PF.S: Same.
  • libc/pmstring/strncasecmp_PF.S: Same.
  • libc/pmstring/strncat_PF.S: Same.
  • libc/pmstring/strncmp_PF.S: Same.
  • libc/pmstring/strncpy_PF.S: Same.
  • libc/pmstring/strnlen_PF.S: Same.
  • libc/pmstring/strstr_PF.S: Same.

Please review.

(file #29336)

Pitchumani <pitchumani>
Project Member
Wed 09 Oct 2013 09:58:51 AM UTC, comment #4:

> comment #2
> I've changed the LPM_R0_ZPLUS_* macros in common/macros.inc to look for AVR_HAVE_ELPM instead of BIG_CODE.
>My guess is that there are still problems because of finding the definition of AVR_RAMPZ_ADDR.


RAMPZ register address is defined based on RAMPZ macro in device header file. Building library for specific arch will result in error as AVR_RAMPZ_ADDR is not defined.

(include/avr/common.h)
284 #if defined(RAMPZ)
285 # define AVR_RAMPZ_REG RAMPZ
286 # if _AVR_ARCH_ >= 100
287 # define AVR_RAMPZ_ADDR _SFR_MEM_ADDR(RAMPZ)
288 # else
289 # define AVR_RAMPZ_ADDR _SFR_IO_ADDR(RAMPZ)
290 # endif
291 #endif

It is possible to hard-code RAMPZ register address irrespective of device header file (gcc also hard-codes RAMPZ address) as follows:

+# define AVR_RAMPZ_REG (_SFR_IO8(0x3b))
+# define AVR_RAMPZ_ADDR (_SFR_IO8(0x3b))

This will enable building library for a architecture than a device.
--
This fix shall be included until we have per device library build system - Joerg Wunsch (http://lists.nongnu.org/archive/html/avr-libc-dev/2013-10/msg00002.html)

Pitchumani <pitchumani>
Project Member
Tue 08 Oct 2013 07:20:05 PM UTC, comment #3:

If someone fixes this issue, please don't forget to reset RAMPZ to 0 after changing it. This is necessary for devices that have RAMPD. Otherwise, reading vom RAM using indirect Z addressing might read from the wrong address. For devices without RAMPD, RAMPZ need not to be reset to 0.

Cf. also the notes on RAMPx in the GCC docs at http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html

Georg-Johann Lay <gjlayde>
Mon 26 Sep 2011 05:10:25 PM UTC, comment #2:

I've changed the LPM_R0_ZPLUS_* macros in common/macros.inc to look for _AVR_HAVE_ELPM_ instead of BIG_CODE.

My guess is that there are still problems because of finding the definition of AVR_RAMPZ_ADDR.

To really fix this, avr-libc needs to build a library-per-device.

Eric Weddington <arcanum>
Project Administrator
Thu 15 Sep 2011 05:43:33 PM UTC, comment #1:

This appears to be a consequence of the problem reported in https://savannah.nongnu.org/patch/?6352 (thus duplicate).

Jan Waclawek <wek>
Tue 29 Mar 2011 06:05:42 PM UTC, original submission:

It looks like that the pmstring code uses the LPM_R0_ZPLUS_* macros von common/macros.inc, which will only use the 'elpm' if _AVR_ENHANCED_ is set. Unfortunately this is no longer used??

Therefore memcmp_PF etc. don't work with atmega1284p or probably other 128k devices.

As I'm not familiar with the setting of flags for the family avr51 I have no idea for a path

Thomas Kaiser <th_k>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #29336:  restore-rampz.patch added by pitchumani (6kB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by pitchumani (Posted a comment)
  • -unavailable- added by gjlayde (Posted a comment)
  • -unavailable- added by arcanum (Posted a comment)
  • -unavailable- added by wek (Posted a comment)
  • -unavailable- added by th_k (Submitted the item)
  •  

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

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 09 Oct 2013 01:08:19 PM UTCpitchumaniAttached File-=>Added restore-rampz.patch, #29336
    Fri 16 Nov 2012 06:56:55 PM UTCarcanumPriority5 - Normal=>9 - Immediate
    Mon 26 Sep 2011 05:10:47 PM UTCarcanumStatusNone=>In Progress
    Mon 26 Sep 2011 05:10:25 PM UTCarcanumSeverity3 - Normal=>5 - Blocker
      Percent Complete0%=>50%

    Back to the top


    Powered by Savane 3.1-cleanup