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

 
 

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

bug #32945: Wrong PF implementation in pmstring

Submitter:  Thomas Kaiser <th_k>
Submitted:  Tue 29 Mar 2011 06:05:42 PM UTC
   
 
Category:  Library Severity:  5 - Blocker
Priority:  9 - Immediate Item Group:  libc code
Status:  In Progress Assigned to:  None
Percent Complete:  50% Open/Closed:  Open
Release:  1.7.* Fixed Release:  None

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>
Group 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>
Group 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>
Group 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.)

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-09 pitchumani Attached File- Added restore-rampz.patch, #29336
    2012-11-16 arcanum Priority5 - Normal 9 - Immediate
    2011-09-26 arcanum StatusNone In Progress
    2011-09-26 arcanum Severity3 - Normal 5 - Blocker
        Percent Complete0% 50%

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code