GCC 6.1.0, strings and PROGMEM

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GCC 6.1.0, strings and PROGMEM

Alan Burlison
I've just updated my toolchain to use GCC 6.1.0 and I notice that
constant C strings seem to be being placed automatically in PROGMEM,
rather than requiring the use of the PSTR macro as in the past. This
caused me some confusion because call such as printf("foo") started
printing garbage. Here's the proof:

        printf("          ");
     91e:       84 e7           ldi     r24, 0x74       ; 116
     920:       90 e0           ldi     r25, 0x00       ; 0
     922:       9f 93           push    r25
     924:       8f 93           push    r24
     926:       0e 94 04 17     call    0x2e08  ; 0x2e08 <printf>

      74:       20 20           and     r2, r0
      76:       20 20           and     r2, r0
      78:       20 20           and     r2, r0
      7a:       20 20           and     r2, r0
      7c:       20 20           and     r2, r0
      7e:       00 21           and     r16, r0

I haven't been able to find any mention of this change anywhere. Is
this a deliberate change in gcc behaviour, or a bug?

Thanks,

--
Alan Burlison
--

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|

Re: GCC 6.1.0, strings and PROGMEM

Senthil Kumar Selvaraj

Alan Burlison writes:

> I've just updated my toolchain to use GCC 6.1.0 and I notice that
> constant C strings seem to be being placed automatically in PROGMEM,
> rather than requiring the use of the PSTR macro as in the past. This
> caused me some confusion because call such as printf("foo") started
> printing garbage. Here's the proof:
>
>         printf("          ");
>      91e:       84 e7           ldi     r24, 0x74       ; 116
>      920:       90 e0           ldi     r25, 0x00       ; 0
>      922:       9f 93           push    r25
>      924:       8f 93           push    r24
>      926:       0e 94 04 17     call    0x2e08  ; 0x2e08 <printf>
>
>       74:       20 20           and     r2, r0
>       76:       20 20           and     r2, r0
>       78:       20 20           and     r2, r0
>       7a:       20 20           and     r2, r0
>       7c:       20 20           and     r2, r0
>       7e:       00 21           and     r16, r0
>
> I haven't been able to find any mention of this change anywhere. Is
> this a deliberate change in gcc behaviour, or a bug?

It looks correct to me. From the dissassembly output, I guess you're
looking at contents at 0x0074 in the flash address space. You should
be looking at contents in the data address space instead. Can you try
dumping contents of the .data section, like so (assuming a.out is the ELF output)

$ avr-objdump -s -j .data a.out

You should see the blank space string at 0x0074 in the output.

Don't know why you're getting garbage output though. Can you post a
testcase that shows the incorrect behavior?

Regards
Senthil
>
> Thanks,
>
> --
> Alan Burlison


_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|

Re: GCC 6.1.0, strings and PROGMEM

Senthil Kumar Selvaraj

Senthil Kumar Selvaraj writes:

> Alan Burlison writes:
>
>> I've just updated my toolchain to use GCC 6.1.0 and I notice that
>> constant C strings seem to be being placed automatically in PROGMEM,
>> rather than requiring the use of the PSTR macro as in the past. This
>> caused me some confusion because call such as printf("foo") started
>> printing garbage. Here's the proof:
>>
>>         printf("          ");
>>      91e:       84 e7           ldi     r24, 0x74       ; 116
>>      920:       90 e0           ldi     r25, 0x00       ; 0
>>      922:       9f 93           push    r25
>>      924:       8f 93           push    r24
>>      926:       0e 94 04 17     call    0x2e08  ; 0x2e08 <printf>
>>
>>       74:       20 20           and     r2, r0
>>       76:       20 20           and     r2, r0
>>       78:       20 20           and     r2, r0
>>       7a:       20 20           and     r2, r0
>>       7c:       20 20           and     r2, r0
>>       7e:       00 21           and     r16, r0
>>
>> I haven't been able to find any mention of this change anywhere. Is
>> this a deliberate change in gcc behaviour, or a bug?
>
> It looks correct to me. From the dissassembly output, I guess you're
> looking at contents at 0x0074 in the flash address space. You should
> be looking at contents in the data address space instead. Can you try
> dumping contents of the .data section, like so (assuming a.out is the ELF output)
>
> $ avr-objdump -s -j .data a.out
>
> You should see the blank space string at 0x0074 in the output.
>
> Don't know why you're getting garbage output though. Can you post a
> testcase that shows the incorrect behavior?
>

Filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 to track this.

Regards
Senthil

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|

Re: GCC 6.1.0, strings and PROGMEM

Alan Burlison
On 16/05/2016 18:13, Senthil Kumar Selvaraj wrote:

> Filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 to track this.

Thanks :-) I see from the bug there's a workaround. Are there any
compelling features in 6.x that make it worth using that, or is it
better to just stick with 5.x until there's a fix for 6.x?

--
Alan Burlison
--

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|

Re: GCC 6.1.0, strings and PROGMEM

Senthil Kumar Selvaraj

Alan Burlison writes:

> On 16/05/2016 18:13, Senthil Kumar Selvaraj wrote:
>
>> Filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 to track this.
>
> Thanks :-) I see from the bug there's a workaround. Are there any
> compelling features in 6.x that make it worth using that, or is it
> better to just stick with 5.x until there's a fix for 6.x?

I'd prefer to stick to 5.x until all the 6.x issues are ironed out.

Regards
Senthil
>
> --
> Alan Burlison


_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|

Re: GCC 6.1.0, strings and PROGMEM

Alan Burlison
On 19/05/2016 11:56, Senthil Kumar Selvaraj wrote:

>> Thanks :-) I see from the bug there's a workaround. Are there any
>> compelling features in 6.x that make it worth using that, or is it
>> better to just stick with 5.x until there's a fix for 6.x?
>
> I'd prefer to stick to 5.x until all the 6.x issues are ironed out.

Will do, thanks :-)

--
Alan Burlison
--

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list