FS#49284 - [avr-gcc] 6.1.1 does not work correctly with character strings in ram.
Attached to Project:
Community Packages
Opened by Jaroslaw Siebert (y0g1) - Tuesday, 10 May 2016, 06:34 GMT
Last edited by Anatol Pomozov (anatolik) - Tuesday, 01 November 2016, 16:38 GMT
Opened by Jaroslaw Siebert (y0g1) - Tuesday, 10 May 2016, 06:34 GMT
Last edited by Anatol Pomozov (anatolik) - Tuesday, 01 November 2016, 16:38 GMT
|
Details
Description:
I recompiled my program for atmega1284 and mostly it works. The only problem is with character strings located in ram - they didn't display correctly. Maybe it is needed to recompile avr-libc with new avr-gcc? Additional info: * package version(s) * config and/or log files etc. Steps to reproduce: compile any program for avr with avr-gcc-6.1.1 and see if it works. |
This task depends upon
I found other bug description on: http://blog.zakkemble.co.uk/avr-gcc-6-1-0/comment-page-1/
"There seems to be a bug with 6.1.0 when compiling with -ffunction-sections and any optimization level other than -O0, where strings passed to a function will be stored in flash instead of RAM even though PSTR() hasn’t been used.
puts("test"); // "test" is incorrectly stored in flash, puts() will attempt to read from RAM!
A work around is to the store the string in a variable then pass that to the function:
that will allow using strings located in ram (stack).
static const char myString[] = "test";
puts(myString);
"
But I don't think that doing that is a real work around.
I would stay with avr-gcc-5.x.x and wait for real solution.
I used it for testing and there is no problems so far.
First tests: some of my programs doesn't compile. There are errors:
/tmp/ccIqFmqw.ltrans14.ltrans.o: In function `check_pakiet_print':
<artificial>:(.text.check_pakiet_print+0x660): relocation truncated to fit: R_AVR_7_PCREL against `no symbol'
collect2: error: ld returned 1 exit status
Testing program that compiles without errors doesn't work correctly. Maybe we need to recompile avr-libc.
Recompilation avr-libc didn't help
The results are worst than before upstream fix (6.1.1-2). I will do more tests later when I will be back.
I was waiting for new gcc-6 snapshot.
After using gcc snapshot: 6-20160811
my test programs works ok. With and without option -fno-merge-constants.
So use snapshot from 20160811 (not 20160804)
I tested it, but the results are the same.
What is strange - that when I recompilled your package from sources - it was broken.
I installed my version build on 18.08.2016 (20160811 snapshot) and it worked.
Then I recompiled today the same snapshot but using archlinux with testing repo enabled, and
avr-gcc I get is broken like yours.
So something wrong with build process. But what I remember from past - always when I build avr tools
I do it in the same order and always complete:
1. avr-binutils
2. avr-gcc
3. avr-libc
I never did it in seperation. And one important point - when I updated host compiler (gcc) and I updated
one of avr packages then I needed to update all of them in proper order.
All of these 3 packages should be built with te same host compiler version and binutils
I do these 3 steps now (avr-binutils, avr-gcc, avr-libc) and will check if it helps.
My tysts from 18.08.2016 (20160811 snapshot) was broken (I don't know why, but I build 5.3 version, not snapshot from 20160811)
So I don't have any correct avr-gcc-6 installation. The only correct results was with avr-gcc-6.1.0 (first testing release) and compiler
option -fno-merge-constants.
Nowadays, even -fno-merge-constants doesn't help. The only solution for me is to remove string tables from ram space. Without them, I can
run programs compiled with avr-gcc (I tested also gcc-6.2.0 version)
I would like to see community version of avr-gcc in archlinux repo, so let me know if you will find how to fix it.
The best way you can do is to report to upstream and actively work with them on fixing the issue.
Please report your findings to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151
there is another bug (from binutils) that cuse problems with avr-gcc 6.
This bug is responsible for relocation regression:
https://sourceware.org/bugzilla/show_bug.cgi?id=20545
It is already fixed in git.
First solution: remove -mrelax option.
Second solution: use binutils from git
Today I compiled binutils from git and gcc from latest snapshot (20161027)
I did first tests. Programs compile without relocation errors. They work without errors (but I did remote tests only).
In few days I will do more tests with more devices. I hope that finally avr tools
will work stable with latest gcc and binutils.
Lets wait for new release of binutils or compile it from git.
There is no more bugs mentioned in this topic.
avr-binutils-2.27-2
avr-gcc-6.2.0-2
avr-libc-2.0.0-1
from repositories.
Programs, that didn't compile with previous avr-binutils now compile.
Remote testing give me positive results. They work without known problems.
We have got functional avr toolchain again.
It is time to close this bug report.