Hi, I was tracking one bug in gcc 4.7.0 (20.4.2012), maybe it helps somebody else to save his time.
I was working on bootloader with Xmodem download feature for ATmega88pa. Because of limited boot section space to 2kB I had to optimize a lot. This was reason why I switched from gcc 4.3.3 to 4.7.0 because it shorted code size ~150B - nice. But it introduced a bug that cause strange hang in Xmodem receiver function. I had allocaded one static Byte buffer for data and when ~30 bytes received it crashed. After hours of messing around I found it happen due to wrong .bss section position. When the buffer was not static it worked because it was placed ijn stack. Or if I made some global variables that filled section. data.
In the map file I saw, that when .data section was empty the linker placed .bss section (the buffer) at address 0x60! Instead of 0x100 - the beginning of SRAM. To prevent it I have to made just one byte global variable (that was used to prevent gcc optimizer to remove it), then .bss was correctly from 0x102 (after that glob. var.). Now you can imagine what happened when Xmodem receiver was writting to buffer at 0x60 - it completly rewite system registers - I also saw that LED flashed shortly when written to PORTB before it crashed [note: as I was debugging UART transaction I couldn't use the same UART for debug prints so I could just debug via LED]....
Also I have to note that I use -fdata-sections -ffunction-sections --gc-sections options to remove unused sections. But gcc was probably too agressive and removed whole empty data section that caused .bss shift.
Anyway when I just a hour ago started to read this thread I found there's gcc 4.7.1 RC package that has updated linker scripts and it solved this problem. It's enough to copy LDSCRIPTS dir to my 4.7.0 compiler package to fix it, so thanks for it. For users experienced with this new gcc 4.7.x what do you reccomend? Should I completly update to 4.7.1 or just the linker scripts to 4.7.0?
I also had one issue caused by avr-libC 1.8.0 at ATmega128:
when I included I got an error due to poisoned SPMCR. I found that boot.h check it's presence via #ifdef that is enough to not compile my source. I also found that this bug was reported and is still opened. My hotfix was simply to comment the poison line in
IOM128.H:
// #pragma GCC poison SPMCR // cause error in boot.h header that test this macro
I don't know better solution but as both SPMCR and SPMSCR regs are defined same way I don't care...
Posted by demiurg_spb: Thu. Aug 30, 2012 - 07:40 AM
1
2
3
4
5
Total votes: 0
glaux wrote:
what do you reccomend? Should I completly update to 4.7.1 ...?
I think that avr-gcc-4.7.1 should be better choice.
SprinterSB wrote:
You must do someting wrong...
Maybe yes, maybe no...
I forgot to say that I use -flto as -combine like manner.
I can't produce minimal test case to show this situation.
Warning is gone if I make simple project with 2 src files main.c and module.c (this module.c is cause warning in real project). Also real project compiles without warnings if I remove -Wextra flag.
IMHO, this is not normal situation
Because next case
static const int PROGMEM x;
produces correct warning in any cases with and without -Wextra flag.
Posted by SprinterSB: Thu. Aug 30, 2012 - 01:02 PM
1
2
3
4
5
Total votes: 0
glaux wrote:
when .data section was empty the linker placed .bss section (the buffer) at address 0x60! Instead of 0x100 [...] Also I have to note that I use -fdata-sections -ffunction-sections --gc-sections options to remove unused sections. But gcc was probably too agressive and removed whole empty data section
GCC does not remove empty section.
You hit binutils PR13697. To work around you can use up to date binutils, patch your default ld script as indicated by the patch along with PR13697, or put some data into .data that cannot be removed.
glaux wrote:
Anyway when I just a hour ago started to read this thread I found there's gcc 4.7.1 RC package that has updated linker scripts and it solved this problem. It's enough to copy LDSCRIPTS dir to my 4.7.0 compiler package to fix it, so thanks for it.
Yes, that will suffice to fix PR13697 but notice that 4.7.1 has more bugs fixed than yust that one. Have a look at the source directory of the 4.7.1rc1 and at GCC bugzilla.
glaux wrote:
For users experienced with this new gcc 4.7.x what do you reccomend? Should I completly update to 4.7.1 or just the linker scripts to 4.7.0?
I'd recommend to update to 4.7.1.
glaux wrote:
I also had one issue caused by avr-libC 1.8.0 at ATmega128:
when I included I got an error due to poisoned SPMCR.
This is AVR-Libc issue #36410.
avrfreaks does not support Opera. Profile inactive.
[Try to] work out a small test case. Most code in your C files won't be needed to reproduce the warning. Remind that others don't have files that you #include.
The compiler option you use
The compiler version you use
The compiler output/messages/diagnostics
You can get 2. 3. and 4. by adding -v to the compiler command options.
avrfreaks does not support Opera. Profile inactive.
Posted by demiurg_spb: Wed. Sep 5, 2012 - 08:25 AM
1
2
3
4
5
Total votes: 0
SprinterSB wrote:
[Try to] work out a small test case. Most code in your C files won't be needed to reproduce the warning. Remind that others don't have files that you #include.
I can't do minimal case. When I exclude any module from my project I get no error :-(
Posted by demiurg_spb: Tue. Sep 11, 2012 - 01:40 PM
1
2
3
4
5
Total votes: 0
SprinterSB wrote:
Can't you compiler with -Wno-error=uninitialized for a start?
with -Wno-error=uninitialized project compiles without any errors but with warnings.
In file included from :117:0:
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]
In file included from :92:0:
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]
SprinterSB wrote:
And -fwhole-program does not look like a good idea of you use LTO.
There is no difference (I've tried to compile without whole-program).
SprinterSB wrote:
Are you sure you have extern in prototypes in the headers?
Posted by SprinterSB: Tue. Sep 11, 2012 - 09:07 PM
1
2
3
4
5
Total votes: 0
Would you attach a zip containing
all needed sources
a plain text file that lists the commands and options that trigger the warning
Please make sure that there are no external dependencies like missing headers that avoid that someone alse can reproduce it.
For example you can inflate zu zip into an empty directory and run the collected compile/assemble/link commands there in order to make sure it actually reproduces the issue.
avrfreaks does not support Opera. Profile inactive.
Hi,
I just downloaded AVR-GCC-4.7.2. Tried to compile an existing project where I have used PROGMEM. I am getting errors!!! The earlier version compiled OK. Thanks for any suggestions.
Hi,
const char PROGMEM ch; works. No errors are reported.
Used makefile and PN for compiling an existing project. Avr-size has thrown out error. It does not understand --mcu option. Avr-size seems to be original GCC size without the extra mcu option.
One question- what is the maximum size of a pointer that is allowed in this release? My primary interest is in having 32 bit pointers. Thank you.
Posted by SprinterSB: Mon. Sep 17, 2012 - 05:28 PM
1
2
3
4
5
Total votes: 0
Magister wrote:
in 4.7.2 you need to use __flash.
Not quite. you may use __flash but there is no need to use __flash. You can just as well use attribute progmem aka. PROGMEM macro together with the pgm_read_* accessors from AVR-Libc.
Nayani P wrote:
I tried to compile an existing project where I have used PROGMEM. I am getting errors!!!
Very descriptive, really...
Presumably you are tring to put non-const data into flash. We don't know.
Nayani P wrote:
avr-size has thrown out error. It does not understand --mcu option.
avr-size is from binutils. It comes without -C kludge or similar. Read the binutils documentation or avr-size --help to learn about supported command options.
Nayani P wrote:
what is the maximum size of a pointer that is allowed in this release? My primary interest is in having 32 bit pointers.
Pointers in the impementation are 16 bits wide. There are no 32-bit pointers.
There is a 24-bit address space __memx which is a C extension. __memx linearizes flash and internal RAM. Read the compiler documentation and the GCC release notes.
avrfreaks does not support Opera. Profile inactive.
Posted by SprinterSB: Fri. Sep 28, 2012 - 07:27 PM
1
2
3
4
5
Total votes: 0
GCC 4.7.2 is released now and I decided to provide a build of avr-gcc 4.7.2 for MS Windows.
If you are interested, see avr-gcc 4.7 for Windows in the avr-gcc-list mailing list archive.
For questions and feedback, please follow up to that mailing list. For details like subscribing to that list, see the avr-gcc-list@nongnu.org main page.
Thanks.
avrfreaks does not support Opera. Profile inactive.
I copied avr-size.exe from AVR tool chain that comes with AVR Studio 5.1.208 to be able to use AVR GCC 4.7.2 with AVR Studio 5. I have not checked to see if the result is correct.
C option is not supported. So, how can I modify AVR Studio 5 to use original avr-size.exe that comes with avr-gcc-4.7.2-mingw32
Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..
Posted by demiurg_spb: Thu. Oct 11, 2012 - 06:23 AM
1
2
3
4
5
Total votes: 0
metal wrote:
So, how can I modify AVR Studio 5 to use original avr-size.exe that comes with avr-gcc-4.7.2-mingw32
avr-size that comes with avr-gcc-4.7.2-mingw32 is unpatched and don't knows avr-format (C option is not supported). Just use old (patched) avr-size.exe from WinAvr or AvrStudio.
You can check path and version of avr-size by next two commands:
"which avr-size.exe"
"avr-size.exe --v"
Magister wrote:
I am using it for a few days now, no difference with the release candidate I think.
I see different to previous version (-18 bytes on 70 KB project) :-).
what is the reason for not patching avr-size.exe to have the required options.
Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..
what is the reason for not patching avr-size.exe to have the required options.
It was a patch developed by Eric Weddington. While the source may be open (I think it has to be as avr-size is likely GPL) the fact is that it would require maintenance as modern tool chains cover a whole load of new AVRs. So only if someone's willing to invest the time/effort (which I guess wouldn't be THAT complex) can a version that matches the device support in a typical 4.6/4.7/4.8 build be produced.
I think I looked at this before and as you may guess it's just a table of device names together with their flash, RAM and EEPROM sizes so -C can show percentages.
As Atmel have taken on the gauntlet of new device additions (in their private branch) you might hope that they would have thought of doing this work. However their choice was to run the vanilla avr-size then run their own post-processor that digests the output then fails to show percentages correctly. Ho hum.
(I think Atmel may have done it that way as they wanted a common mechanism that could work with AVR32 and SAM3/4 too).
EDIT:
E:\WinAVR-20100110\source\avr\binutils\2.19>dir 30*
Volume in drive E is VBOX_windows
Volume Serial Number is 0000-0801
Directory of E:\WinAVR-20100110\source\avr\binutils\2.19
19/01/2010 19:08 16,260 30-binutils-2.19-avr-size.patch
Clearly that needs to be brought up from 2.19 to 2.22 or whatever.
EDIT2: hey I'm famous. I was searching for "{"atmega164p", AVR16K, AVR1K, AVR512}" online to see if I could find a maintained copy of the patch and it hit this site:
Posted by indianajones11: Thu. Oct 18, 2012 - 07:52 PM
1
2
3
4
5
Total votes: 0
I asked on the 1st pg. if this toolchain could be used with Studio 4.18, and from Clawson's reply I tried adding its path, for avr-gcc-4.7.2.exe, in Custom Options. I'm confused about MAKE.exe, since it's not in the chain. I assume then that I can use the same one from Winavr, so that path's unchanged.
I tested it on my MP3 pjt, using FATFS and this is the output: 1st warning in ff.c:347:3( the return line )
Build started 18.10.2012 at 12:29:06
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes" -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99 -fno-inline-small-functions -ffunction-sections -fdata-sections -mcall-prologu
es -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT ff.o -MF dep/ff.o.d -c ../ff.c
../ff.c: In function 'get_fat':
../ff.c:347:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:351:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c: In function 'check_fs':
../ff.c:1445:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1448:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1450:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c: In function 'chk_mounted':
../ff.c:1531:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1535:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1536:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1540:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1542:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1543:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1544:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1546:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1554:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes" -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99 -fno-inline-small-functions -ffunction-sections -fdata-sections -mcall-prologu
es -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT LCD.o -MF dep/LCD.o.d -c ../LCD.c
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes" -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99 -fno-inline-small-functions -ffunction-sections -fdata-sections -mcall-prologu
es -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT vs1011.o -MF dep/vs1011.o.d -c ../vs1011.c
../vs1011.c: In function 'sd_cmd':
../vs1011.c:39:2: warning: right shift count >= width of type [enabled by default]
../vs1011.c: In function 'VS_sci_rd':
../vs1011.c:247:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes" -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99 -fno-inline-small-functions -ffunction-sections -fdata-sections -mcall-prologu
es -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT diskio.o -MF dep/diskio.o.d -c ../diskio.c
../diskio.c:187:6: warning: 'select' defined but not used [-Wunused-function]
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes" -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99 -fno-inline-small-functions -ffunction-sections -fdata-sections -mcall-prologu
es -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT mp3.o -MF dep/mp3.o.d -c ../mp3.c
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes" -mmcu=atxmega16a4 -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99 -fno-inline-small-functions -ffunction-sections -fdata-sectio
ns -mcall-prologues -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT ccp.o -MF dep/ccp.o.d -x assembler-with-cpp -Wa,-gdwarf2 -c ../ccp.S
avr-gcc-4.7.2 -mmcu=atxmega16a4 -Wl,--relax -Wl,--gc-sections -Wl,-Map=My_MP3.map ff.o LCD.o vs1011.o diskio.o mp3.o ccp.o -L"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\MY_LIBS" -lm -o My_MP3.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature My_MP3.elf My_MP3.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex My_MP3.elf My_MP3.eep || exit 0
avr-objdump -h -S My_MP3.elf > My_MP3.lss
avr-size: invalid option -- C
Usage: avr-size [option(s)] [file(s)]
Displays the sizes of sections inside binary files
If no input file(s) are specified, a.out is assumed
The options are:
-A|-B --format={sysv|berkeley} Select output style (default is berkeley)
-o|-d|-x --radix={8|10|16} Display numbers in octal, decimal or hex
-t --totals Display the total sizes (Berkeley only)
--common Display total size for *COM* syms
--target= Set the binary file format
@ Read options from
-h --help Display this information
-v --version Display the program's version
avr-size: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex
make: *** [size] Error 1
Build failed with 1 errors and 17 warnings...
It's fine with the latest Winavr and I'm missing something(s)...
1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1
Posted by indianajones11: Thu. Oct 18, 2012 - 08:08 PM
1
2
3
4
5
Total votes: 0
Bingo600 wrote:
Sprinter is building a plain-vanilla avr-gcc.
avr-size (Binutils) hasn't been patched with the "Atmel patches"
Just skip the "Atmel specific option -C" avr-size step , or apply the Atmel patch called something like 30-binutils-avr-size.patch
/Bingo
1) Skipping -C option...how, that's in Atmel's MAKEFILE isn't it ?
OR
2) Patch option... I don't have a clue how to apply it. I can find it. I'm running 'Doze XP.
Thanks for the help.
1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1
Posted by indianajones11: Thu. Oct 18, 2012 - 09:27 PM
1
2
3
4
5
Total votes: 0
Bingo600 wrote:
If you have no clue on using patch ...
/Bingo
Yeah, I found the patch on their site, but nothing on how to install it in 'Doze XP. Much easier in Linux, I bet. It looks like just a C file, I was thinking it would be a *.exe file to integrate into the toolchain.
Quote:
I'd select option 1 , and find the place in the makefile where avr-size gets called.
Then either comment it out , or at least remove the -C
When I comment out the line or even take out just the option, MAKEFILE doesn't keep the saved changed . I edit Atmel's MAKEFILE, save it and rebuild...original line's back ( what voodoo is this ??! ). All the warnings go away, though.
Jerome
1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1
Posted by indianajones11: Thu. Oct 18, 2012 - 09:42 PM
1
2
3
4
5
Total votes: 0
I read freaky member demiurg_spb's reply above on this pg. , thanks man, and so I just copied Winavr's avr-size.exe in place of 4.7.2's and it complies now, but the same 17 warnings are back.
Xmega16A4, -Os
Winavr compile: 7218 bytes
AVR-GCC 4.7.2 compile: 6914
Thanks Sprinter for all your work.
Edit: This switch used to turn those warnings off, produced from FATFS code ( must be a harmless warning in this case ):
-fno-strict-aliasing
1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1
Yes, but that in turn has not included the binutils PR13503 fix.
an1.s: Assembler messages:
an1.s:23: Error: junk at end of line, first unrecognized character is `('
an1.s:24: Error: junk at end of line, first unrecognized character is `('
an1.s:25: Error: junk at end of line, first unrecognized character is `('
.global pfoo
.section .progmem.data,"a",@progbits
.type pfoo, @object
.size pfoo, 3
pfoo:
.byte lo8(foo) ; need binutils PR13503
.byte hi8(foo) ; need binutils PR13503
.byte hh8(foo) ; need binutils PR13503
I know it is possible to compile using the 4.7.1 and assemble and link using the tools from the 4.7.2 build, but if it is not a big hassle for you, it would be nice to have it as a single bundle working "out-of-the-box".
The 4.7.2 bundle has seen already a couple of dozens of downloads. There *is* a need for this stuff, in lack of a WinAVR-style package.
an12.s: Assembler messages:
an12.s:24: Warning: assembling 24-bit address needs binutils extension for hh8(d
ummy1)
an12.s:23: Error: value of 98305 too large for field of 2 bytes at 0
(line 23 is .word dummy1 )
I (and presumably others too) would be obliged if you could find time to produce a working set of binaries.
(Just wondering, how does "does not produce assemblable code" fail short of the official definition of "bug").
Okay, but aren't both already present in 4.7.x? If so, that's no real gotcha in using a 4.8 snapshot rather than a 4.7.whatever release.
I mean, users presumably would try 4.7+ mainly to test the new features, of which IMO __flash and kin are the most interesting and worth more thorough testing and further discussion.
I did not mention it, but I now started asking for these things just because somebody else asked for string literals in high FLASH (pointers to) arrays also in high FLASH (*), in a local mailing list. I in answer recommended the newest development in 4.7+ just to be told that it does not work...
JW
(*) I tried to keep the C type declaration style :-)
Posted by SprinterSB: Wed. Nov 21, 2012 - 10:26 PM
1
2
3
4
5
Total votes: 0
It work for me with __flash1 etc.
Notice one segment cannot hold more than 64KiB and you need a liker script as explaned in the GCC docs. Ther is no one-fits-all-memory-arrangements script, at least I failed in finding one. Maybe just because my very limited knowledge on binutils and a wizard finds an nea solution...
avrfreaks does not support Opera. Profile inactive.
The only error there is the attempt to use -C on avr-size. The fact is that in WinAVR Eric Weddington developed/applied a patch to avr-size utility so that as well as the normal -A and -B that the generic "size" program accepts it would now accept -C along with an additional --mcu= so it could produce a much more readable output display that even included % of flash and data figures. It does this as it has a large table of all the known AVR models along with their flash, RAM and EEPROM sizes. The version of avr-size you are using does not have this patch. So edit the Makefile you are using and stop it attempting to use -C and --mcu=.
Alternatively find out what version of avr-size is now being used and temporarily replace it with the avr-size.exe copied from WinAVR as the old version should still work on "modern" .elf files.
Thanks clawson for the answer seems the reason is quiet clear and known by avr freaks.
the problem is What I'm not sure I know how to do everything you wrote above. Can you write some short description how to update avr-size content and how to edit MakeFile? It will be very helpfully for me and I think for others too.
As you can see, on my machine the one being used is the one in WinAVR2010. I guess (assuming which.exe can also be found!) your machine is going to give the path to the "new" version. Once you locate it rename it out of the way:
ren avr-size.exe avr-size.new
Then copy the old one from WinAVR in to that same place so it will now be found.
with
avr-gcc foo.c -Os -S -Wextra -Wall -W -std=gnu99 -pedantic
there is no warning.avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Topsry doublepost-delete this
- Log in or register to post comments
TopHi, I was tracking one bug in gcc 4.7.0 (20.4.2012), maybe it helps somebody else to save his time.
I was working on bootloader with Xmodem download feature for ATmega88pa. Because of limited boot section space to 2kB I had to optimize a lot. This was reason why I switched from gcc 4.3.3 to 4.7.0 because it shorted code size ~150B - nice. But it introduced a bug that cause strange hang in Xmodem receiver function. I had allocaded one static Byte buffer for data and when ~30 bytes received it crashed. After hours of messing around I found it happen due to wrong .bss section position. When the buffer was not static it worked because it was placed ijn stack. Or if I made some global variables that filled section. data.
In the map file I saw, that when .data section was empty the linker placed .bss section (the buffer) at address 0x60! Instead of 0x100 - the beginning of SRAM. To prevent it I have to made just one byte global variable (that was used to prevent gcc optimizer to remove it), then .bss was correctly from 0x102 (after that glob. var.). Now you can imagine what happened when Xmodem receiver was writting to buffer at 0x60 - it completly rewite system registers - I also saw that LED flashed shortly when written to PORTB before it crashed [note: as I was debugging UART transaction I couldn't use the same UART for debug prints so I could just debug via LED]....
Also I have to note that I use -fdata-sections -ffunction-sections --gc-sections options to remove unused sections. But gcc was probably too agressive and removed whole empty data section that caused .bss shift.
Anyway when I just a hour ago started to read this thread I found there's gcc 4.7.1 RC package that has updated linker scripts and it solved this problem. It's enough to copy LDSCRIPTS dir to my 4.7.0 compiler package to fix it, so thanks for it. For users experienced with this new gcc 4.7.x what do you reccomend? Should I completly update to 4.7.1 or just the linker scripts to 4.7.0?
I also had one issue caused by avr-libC 1.8.0 at ATmega128: I got an error due to poisoned SPMCR. I found that boot.h check it's presence via #ifdef that is enough to not compile my source. I also found that this bug was reported and is still opened. My hotfix was simply to comment the poison line in
when I included
IOM128.H:
// #pragma GCC poison SPMCR // cause error in boot.h header that test this macro
I don't know better solution but as both SPMCR and SPMSCR regs are defined same way I don't care...
- Log in or register to post comments
TopI forgot to say that I use -flto as -combine like manner.
I can't produce minimal test case to show this situation.
Warning is gone if I make simple project with 2 src files main.c and module.c (this module.c is cause warning in real project). Also real project compiles without warnings if I remove -Wextra flag.
IMHO, this is not normal situation
Because next case
produces correct warning in any cases with and without -Wextra flag.
Attachment(s):
- Log in or register to post comments
TopYou hit binutils PR13697. To work around you can use up to date binutils, patch your default ld script as indicated by the patch along with PR13697, or put some data into .data that cannot be removed.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Top>SprinterSB
Thanks for info. I started to use GCC 4.7.1 and currently didn't find any problem.
>This is AVR-Libc issue #36410.
AFAIK still not solved for ~3 months...
- Log in or register to post comments
Topavrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Top- Log in or register to post comments
Top- [Try to] work out a small test case. Most code in your C files won't be needed to reproduce the warning. Remind that others don't have files that you #include.
- The compiler option you use
- The compiler version you use
- The compiler output/messages/diagnostics
You can get 2. 3. and 4. by adding -v to the compiler command options.avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopMay I send You my project directly?
Attachment(s):
- Log in or register to post comments
TopCan't you compiler with -Wno-error=uninitialized for a start?
And -fwhole-program does not look like a good idea of you use LTO.
Can't you reduce it to two or three files?
Are you sure you have extern in prototypes in the headers?
If I don't miss something that the warning is only during the LTO link, not when compiling to .o. Is that right?
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Topwith -Wno-error=uninitialized project compiles without any errors but with warnings.
- Log in or register to post comments
TopWould you attach a zip containing
- all needed sources
- a plain text file that lists the commands and options that trigger the warning
Please make sure that there are no external dependencies like missing headers that avoid that someone alse can reproduce it.For example you can inflate zu zip into an empty directory and run the collected compile/assemble/link commands there in order to make sure it actually reproduces the issue.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopHi,
I just downloaded AVR-GCC-4.7.2. Tried to compile an existing project where I have used PROGMEM. I am getting errors!!! The earlier version compiled OK. Thanks for any suggestions.
Parthasaradhi Nayani
- Log in or register to post comments
Topin 4.7.2 you need to use __flash. I changed all reference to progmem in my code. To define string I am using:
Also SprinterSB, FIY, my project with:
4.7.1 : 15700 bytes
4.7.2 : 15674 bytes
4.8.0 : 15788 bytes
PS: big thanks to you for making avr-gcc build! 8) :D
- Log in or register to post comments
TopHi,
const char PROGMEM ch; works. No errors are reported.
Used makefile and PN for compiling an existing project. Avr-size has thrown out error. It does not understand --mcu option. Avr-size seems to be original GCC size without the extra mcu option.
One question- what is the maximum size of a pointer that is allowed in this release? My primary interest is in having 32 bit pointers. Thank you.
Parthasaradhi Nayani
- Log in or register to post comments
TopPresumably you are tring to put non-const data into flash. We don't know.
There is a 24-bit address space __memx which is a C extension. __memx linearizes flash and internal RAM. Read the compiler documentation and the GCC release notes.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopGCC 4.7.2 is released now and I decided to provide a build of avr-gcc 4.7.2 for MS Windows.
If you are interested, see avr-gcc 4.7 for Windows in the avr-gcc-list mailing list archive.
For questions and feedback, please follow up to that mailing list. For details like subscribing to that list, see the avr-gcc-list@nongnu.org main page.
Thanks.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopI am using it for a few days now, no difference with the release candidate I think.
Thanks a lot for your work, it's highly appreciated!
- Log in or register to post comments
TopI copied avr-size.exe from AVR tool chain that comes with AVR Studio 5.1.208 to be able to use AVR GCC 4.7.2 with AVR Studio 5. I have not checked to see if the result is correct.
C option is not supported. So, how can I modify AVR Studio 5 to use original avr-size.exe that comes with avr-gcc-4.7.2-mingw32
Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..
- Log in or register to post comments
TopYou can check path and version of avr-size by next two commands:
"which avr-size.exe"
"avr-size.exe --v"
- Log in or register to post comments
Topwhat is the reason for not patching avr-size.exe to have the required options.
Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..
- Log in or register to post comments
TopIt was a patch developed by Eric Weddington. While the source may be open (I think it has to be as avr-size is likely GPL) the fact is that it would require maintenance as modern tool chains cover a whole load of new AVRs. So only if someone's willing to invest the time/effort (which I guess wouldn't be THAT complex) can a version that matches the device support in a typical 4.6/4.7/4.8 build be produced.
I think I looked at this before and as you may guess it's just a table of device names together with their flash, RAM and EEPROM sizes so -C can show percentages.
As Atmel have taken on the gauntlet of new device additions (in their private branch) you might hope that they would have thought of doing this work. However their choice was to run the vanilla avr-size then run their own post-processor that digests the output then fails to show percentages correctly. Ho hum.
(I think Atmel may have done it that way as they wanted a common mechanism that could work with AVR32 and SAM3/4 too).
EDIT:
Clearly that needs to be brought up from 2.19 to 2.22 or whatever.
EDIT2: hey I'm famous. I was searching for "{"atmega164p", AVR16K, AVR1K, AVR512}" online to see if I could find a maintained copy of the patch and it hit this site:
https://build.opensuse.org/packa...
So they named the package after my internet persona!
Oh and I did find a 2.20 version:
http://fbsdmon.org/ports/devel/a...
- Log in or register to post comments
TopI asked on the 1st pg. if this toolchain could be used with Studio 4.18, and from Clawson's reply I tried adding its path, for avr-gcc-4.7.2.exe, in Custom Options. I'm confused about MAKE.exe, since it's not in the chain. I assume then that I can use the same one from Winavr, so that path's unchanged.
I tested it on my MP3 pjt, using FATFS and this is the output:
1st warning in ff.c:347:3( the return line )
It's fine with the latest Winavr and I'm missing something(s)...
1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1
- Log in or register to post comments
TopSprinter is building a plain-vanilla avr-gcc.
avr-size (Binutils) hasn't been patched with the "Atmel patches"
Just skip the "Atmel specific option -C" avr-size step , or apply the Atmel patch called something like 30-binutils-avr-size.patch
/Bingo
- Log in or register to post comments
TopOR
2) Patch option... I don't have a clue how to apply it. I can find it. I'm running 'Doze XP.
Thanks for the help.
1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1
- Log in or register to post comments
TopIf you have no clue on using patch ...
I'd select option 1 , and find the place in the makefile where avr-size gets called.
Then either comment it out , or at least remove the -C
/Bingo
- Log in or register to post comments
TopJerome
1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1
- Log in or register to post comments
TopI read freaky member demiurg_spb's reply above on this pg. , thanks man, and so I just copied Winavr's avr-size.exe in place of 4.7.2's and it complies now, but the same 17 warnings are back.
Xmega16A4, -Os
Winavr compile: 7218 bytes
AVR-GCC 4.7.2 compile: 6914
Thanks Sprinter for all your work.
Edit: This switch used to turn those warnings off, produced from FATFS code ( must be a harmless warning in this case ):
1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1
- Log in or register to post comments
TopJohann,
Now that https://www.avrfreaks.net/index.p... has been solved through http://sourceware.org/bugzilla/s... , could you please provide a binary build which removes the initializer problem described under "Limitations and caveats" in http://gcc.gnu.org/onlinedocs/gc... ?
Thanks,
Jan
- Log in or register to post comments
TopThere is avr-gcc-4.7.1-rc1-mingw32.zip that comes with a backport of PR53344 to 4.7, see the source directory for respective patchset.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopYes, but that in turn has not included the binutils PR13503 fix.
I know it is possible to compile using the 4.7.1 and assemble and link using the tools from the 4.7.2 build, but if it is not a big hassle for you, it would be nice to have it as a single bundle working "out-of-the-box".
The 4.7.2 bundle has seen already a couple of dozens of downloads. There *is* a need for this stuff, in lack of a WinAVR-style package.
Thanks,
Jan
- Log in or register to post comments
TopDoes 4.7.2 work for you and instead of compiling / assembling in "one" step
you do two steps like so?
Notice PR53344 won't be backported to 4.7 because the avr port maintainers did not approve a backport which is in accordance with GCC policies:
Bug fixes and documentation changes only.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopApart from the aesthetical drawback that the warning remains, it also simply fails, because:
results in
(line 23 is .word dummy1 )
I (and presumably others too) would be obliged if you could find time to produce a working set of binaries.
(Just wondering, how does "does not produce assemblable code" fail short of the official definition of "bug").
Thanks,
Jan
PS. Johann, could you please also comment on https://www.avrfreaks.net/index.p... ? Thanks.
- Log in or register to post comments
TopHow does the assembler code look like?
And how did you assemble that?
At the moment all the time I can spend on avr-gcc is consumed by other stuff.
I will come back toi this as soon I have some time left.
Thanks for your patience.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopThanks,
Jan
Attachment(s):
- Log in or register to post comments
TopWhat about the 4.8.0 snapshot?
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopWhy not?
You tell what could be a gotcha.
JW
- Log in or register to post comments
TopFixed-Point support is broken by design.
Slighly inefficient reloading because of outdated constraint cost (PR54815).
@@@ A CAPTCHA for this post???
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopOkay, but aren't both already present in 4.7.x? If so, that's no real gotcha in using a 4.8 snapshot rather than a 4.7.whatever release.
I mean, users presumably would try 4.7+ mainly to test the new features, of which IMO __flash and kin are the most interesting and worth more thorough testing and further discussion.
I did not mention it, but I now started asking for these things just because somebody else asked for string literals in high FLASH (pointers to) arrays also in high FLASH (*), in a local mailing list. I in answer recommended the newest development in 4.7+ just to be told that it does not work...
JW
(*) I tried to keep the C type declaration style :-)
- Log in or register to post comments
TopIt work for me with __flash1 etc.
Notice one segment cannot hold more than 64KiB and you need a liker script as explaned in the GCC docs. Ther is no one-fits-all-memory-arrangements script, at least I failed in finding one. Maybe just because my very limited knowledge on binutils and a wizard finds an nea solution...
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
Topsomething is broken in avr-gcc 4.7.2
and in 4.3.3
and in 4.4.3 too :-(
Structures x,y,z and their fields are placed in memory without any gaps.
It seems to be very old bug:https://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=65874&start=0
- Log in or register to post comments
Topplease solution
After update gcc from 4.3 to 4.7.2 I cant compile my code some unseen error appeared
may somebody knows the solution or need some more information...
- Log in or register to post comments
TopThe only error there is the attempt to use -C on avr-size. The fact is that in WinAVR Eric Weddington developed/applied a patch to avr-size utility so that as well as the normal -A and -B that the generic "size" program accepts it would now accept -C along with an additional --mcu= so it could produce a much more readable output display that even included % of flash and data figures. It does this as it has a large table of all the known AVR models along with their flash, RAM and EEPROM sizes. The version of avr-size you are using does not have this patch. So edit the Makefile you are using and stop it attempting to use -C and --mcu=.
Alternatively find out what version of avr-size is now being used and temporarily replace it with the avr-size.exe copied from WinAVR as the old version should still work on "modern" .elf files.
- Log in or register to post comments
TopThanks clawson for the answer seems the reason is quiet clear and known by avr freaks.
the problem is What I'm not sure I know how to do everything you wrote above. Can you write some short description how to update avr-size content and how to edit MakeFile? It will be very helpfully for me and I think for others too.
- Log in or register to post comments
TopWell the simplest would just be to replace the avr-size.exe now being found/used with one that does accept -C. At a Command Prompt type:
As you can see, on my machine the one being used is the one in WinAVR2010. I guess (assuming which.exe can also be found!) your machine is going to give the path to the "new" version. Once you locate it rename it out of the way:
Then copy the old one from WinAVR in to that same place so it will now be found.
- Log in or register to post comments
TopDone.
Working thanks dude, one problem is solved ;]
- Log in or register to post comments
TopThis bug is present with __flash keyword, with PROGMEM everything is ok. Testcase is in attached archive.
Attachment(s):
- Log in or register to post comments
TopWould you file a GCC bug report?
http://gcc.gnu.org/bugzilla/
For more information, see http://gcc.gnu.org/bugs/#report
Thanks.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopI think I know where the problem is. But it will be hard to fix. I cannot say if there will be a working solution for 4.7
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopPages