| Author |
Message |
|
|
 Posted: Aug 15, 2010 - 02:24 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
I have put together a development environment and a set of scripts to build the latest GNU toolchain for Windows.
Please note that EW states that GCC 4.4.x is tested far more throughly than GCC 4.5.1 used in my release, so I would not recommend it for any production situation.
The build scripts and compiled binaries are available at:
http://www.makehackvoid.com/group-projects/mhvavrtools
I'm happy to accept community patches, in particular:
- porting new device patches to GCC 4.5.1
- creating a Nullsoft installer for the package |
|
|
| |
|
|
|
|
|
|
Posted: Aug 15, 2010 - 04:51 PM |
|
Joined: Nov 29, 2007
Posts: 3219
|
|
| May I suggest you bundle it with your library? That way your toolchain would have a distinguishing feature. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 15, 2010 - 10:19 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
| Thanks Arnold, thats a good suggestion. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 08, 2010 - 08:28 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
| Updated recently to include a real installer and smatch for C linting. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 05, 2011 - 01:41 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
Updated to GCC 4.5.2 & AVR LibC 1.7.1.
Also includes GNU Win32 utilities such as rm & friends. |
|
|
| |
|
|
|
|
|
|
Posted: May 08, 2011 - 12:08 AM |
|
Joined: Nov 28, 2004
Posts: 3553
Location: San Diego, Ca
|
|
| Can your binary installed *.exe tool co-exist with studio 4.18 ? |
_________________
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: May 08, 2011 - 05:15 PM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
Hi. First of all, let me say that it's great to have distributions like this that are plain vanilla, leight-weight and come without the additional plethora of GUIs like AStudio!
I tried the 4.5.2 released 2011-03-06 and observed the problem that libgmp-10.dll could not be found. I did not add the path of the toolchain to PATH because I prefer to use the tools by specifying absolute path names like e:/absolute-install-path/bin/avr-gcc directly. (It worked after I added /bin to PATH, but if there are many toolchains installed it might be impossible to find the right order to add their paths to PATH and some toolchains will always use false DLLs).
The problem seem to be that you supply gmp/mpfr/mpc as shared libraries, so I propose adding --disable-shared to your configure options.
Moreover, the process of building avr-gcc is easier and straight forward if you do a in-tree build of the support libraries gmp/mpfr/mpc. To do that, just copy the sources of gmp/mpfr/mpc as "gmp", "mpfr" resp. "mpc" in the top-level gcc source tree (or, at your option, soft-link them).
That way you do not need seperate build steps for these libraries: gcc build machinery will recognize and configure, build and install them as needed. You don't have to give --with-gmp/-mpfr/-mpc any more. It's all handled automatically.
Moreover, some people might want to play around with link time optimization. I didn't try to build avr-gcc-4.5 with LTO yet, but maybe it works out of the box. To do that, just get appropriate version of libelf, link/copy it into gcc top-level source and say --enable-lto.
As GCC 4.6.0 is already released: is there also a 4.6.0 distribution? This might establish a narrower release-test-bugfix cycle. However, note that DWARF2 is broken in avr-gcc >= 4.6, so you would have to remove --with-dwarf2 from configure. See
http://gcc.gnu.org/PR48459
As Eric said, the 4.4 release is far more tested, but how are people supposed to test if there are no easily available distributions that can switched back and forth by changing some path name? Is everyone supposed to instell 3 versions of AStudio 5 just to test 3 releases of avr-gcc? I installed your version on Win2000 and it runs smooth!
Thanks for your work! |
|
|
| |
|
|
|
|
|
|
Posted: May 11, 2011 - 07:51 PM |
|
Joined: Apr 25, 2004
Posts: 3809
Location: Denmark
|
|
@SprinterSB
Speaking about avr-gcc-4.5.x 
Could you mention a good combination of "options" for producing "small code"
Aka. Best practice GCC options for gcc-4.5.x
ie. -fno-split-wide-types
etc ...
/Bingo |
|
|
| |
|
|
|
|
|
|
Posted: May 13, 2011 - 10:23 AM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
|
Bingo600 wrote:
Could you mention a good combination of "options" for producing "small code"
Aka. Best practice GCC options for gcc-4.5.x
I don't think there is a magic combination of options that deflates you code by 10%, except -Os.
There are plenty of options and params; it's almost impossible to test all combinations. You can try to deactivate some of the following switches that are turned on with optimization:
-finline-small-functions
-fmove-loop-invariants
-fsplit-wide-types
-ftree-loop-optimize
-ftree-scev-cprop
It will depend on the code if or if not some switch might safe some bytes.
The biggest impact will have -Os and your coding style. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 06, 2011 - 09:55 AM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
New release:
- Upgrade to GCC 4.6.2
- Upgrade to AVR LibC 1.7.2rc2252
- Upgrade to AVRDUDE 5.11.1
The URL has changed, it can now be found at:
http://www.makehackvoid.com/project/mhvavrtools
I have not yet made the changes that Sprinter suggested. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 06, 2011 - 06:49 PM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
|
evildeece wrote:
- Upgrade to GCC 4.6.2
There is PR50063 that leads to wrong code. Did you disable that pass?
Moreover, -fno-caller-saves might be a good idea. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 06, 2011 - 08:40 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
Not yet, I'll roll off another build soon.
Can these features be disabled at GCC compile time? |
|
|
| |
|
|
|
|
|
|
Posted: Nov 08, 2011 - 04:58 PM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
|
|
|
|
|
|
Posted: Mar 29, 2012 - 11:08 AM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
|
|
|
|
|
|
Posted: Mar 29, 2012 - 11:15 AM |
|
Joined: Jul 18, 2005
Posts: 62371
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
It includes GCC 4.7.0
How close to a 4.7.1 are you? I think that's the one everyone's waiting for! |
_________________
|
| |
|
|
|
|
|
|
Posted: Mar 29, 2012 - 12:43 PM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
|
clawson wrote:
Quote:
It includes GCC 4.7.0
How close to a 4.7.1 are you? I think that's the one everyone's waiting for!
4.7.0 should work will if no new features are used.
That is: If you use some version < 4.7 to compile a project, it should just as well work with 4.7.0.
If everyone just sits and waits for 4.7.1 (and thus no problems are reported) 4.7.1 will make absolutely no difference compared to 4.7.0 for the vase majority of code that don't use new features (that require source changes in the project). Simply becasue if there are no known problems, there won't be fixed for them, of course. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 29, 2012 - 01:12 PM |
|
Joined: Jul 18, 2005
Posts: 62371
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
if no new features are used.
It's the new memory sections and pointer stuff that I think most people (certainly me) want to "play" with. But they want it wrapped up in a user friendly "WinaVR-alike" |
_________________
|
| |
|
|
|
|
|
|
Posted: Mar 29, 2012 - 02:13 PM |
|
Joined: Aug 06, 2008
Posts: 141
Location: Montréal, QC
|
|
and LTO is only fixed in the latest 4.7.1 AFAIK.
I play with 4.7.x for a few months, no problem with it, it optimizes code very well.
I converted all my code to use the new __flash feature, no more PROGMEM. Also I think all the pgm_read_xxxx() functions are being deprecated soon, so better convert your code |
|
|
| |
|
|
|
|
|
|
Posted: Mar 29, 2012 - 03:43 PM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
|
Magister wrote:
and LTO is only fixed in the latest 4.7.1 AFAIK.
LTO already worked in 4.6; the issue is rather with binutils and the windows environment.
Quote:
I play with 4.7.x for a few months, no problem with it, it optimizes code very well.
With current binutils I hit PR13899. Maybe it's best to use 2.21 where I don't see problems. 2.22 don't work for some other reason. I don't know how binutils folk handles backporting of PRs and how the prospects are that PR13899 is fixed. It's avr specific and thus very unlikely...
Quote:
I converted all my code to use the new __flash feature, no more PROGMEM. Also I think all the pgm_read_xxxx() functions are being deprecated soon, so better convert your code
All source should be upward compatible and old code compile just as well without changing anything (except making data in flash read-only as introduced in 4.6, but that has nothing to do with __flash).
__flash is easier to use than pgm_read, in particular when dereferencing structures or mult-level pointers. Maybe __flash is good for new projects, but converting an old project and go through all that pain for nothing and just for nice sources??
I parameterized a project so that it can be built both with __flash and progmem+pgm_read in order to see performance differences or to learn how __flash interacts with real-world code in comparison with pgm. But the sources are ugly, even more ugly as with pgm alone. But with clean __flash there is no way to learn about the difference or performance degradation. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 29, 2012 - 04:07 PM |
|
Joined: Aug 06, 2008
Posts: 141
Location: Montréal, QC
|
|
I use binutils 2.22.52.20120322, so far so good, I did not hit the bug you mention, I will be careful though if something fails.
Also I was wrong, it's not the prog_read_xxxx() functions that are deprecated but the prog_char, prog_uint16_t, etc
On a SVN branch I have my code for 4.7.x, I integrated this in the Makefile to have it compiled with either my 4.3.0 or 4.7.1 :
Code:
GCCVERSION := $(shell echo `avr-gcc -dumpversion`)
ifeq "$(GCCVERSION)" "4.7.1"
CTUNING += -mstrict-X
else
CTUNING += -morder1 -fno-split-wide-types -fno-inline-small-functions
CTUNING += --combine -fwhole-program
CDEFS += -DUSE_PROGMEM
endif
Then in the C code I test USE_PROGMEM to include or not pgmspace.h, have a diff in some prototypes, etc |
|
|
| |
|
|
|
|
|
|
Posted: Mar 29, 2012 - 09:11 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
|
clawson wrote:
Quote:
It includes GCC 4.7.0
How close to a 4.7.1 are you? I think that's the one everyone's waiting for!
Thats more up to the GCC folk than me 
It typically takes me a few hours to put together a new package if I don't need to port anything, so I should be able to mave fairly quikly once 4.7.1 is announced. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 10, 2012 - 11:32 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
MHV AVR Tools 20120709 has been released:
http://www.makehackvoid.com/mhvavrtools-20120709
- Bump to GCC 4.7.1 and Binutils 2.22.52.20120702 (development snapshot)
- Enable LTO
- Enable XMega microcontrollers
Windows (Atom or greater), Linux x86 (Atom or greater) and Linux x64 (Sandybridge or greater) binaries are available now.
OSX will follow soon. |
Last edited by evildeece on Jul 10, 2012 - 11:36 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Jul 10, 2012 - 11:34 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
This release was a real pain to push out. I added a bootstrap step that first builds a native, current compiler and then builds the rest from that. When building AVR binutils and GCC, libtool kept installing the libtool wrappers instead of the actual executables.
I ended up building these components using the MinGW shipped compilers instead. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 11, 2012 - 07:53 AM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
|
evildeece wrote:
GCC 4.7.1 and Binutils 2.22.52.20120702 (development snapshot)
There are some bugs in binutils. See the patches that the following 4.7.1 + 2.23 release applies:
avr-gcc-4.7.1-rc1-mingw32.zip!/source
in
http://sourceforge.net/projects/mobilec ... 20(Win32)/
Some of these issues are upstream meanwhile, others are not... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 11, 2012 - 12:01 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
| Thanks Sprinter |
|
|
| |
|
|
|
|
|
|
Posted: Jul 11, 2012 - 06:37 PM |
|
Joined: Aug 06, 2008
Posts: 141
Location: Montréal, QC
|
|
| FYI, with the MHV tool, my project build to 15670 bytes, with the 4.7.1 of SprinterSB it is 15460 bytes. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 12, 2012 - 08:09 AM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
|
|
|
|
|
|
Posted: Jul 13, 2012 - 03:17 PM |
|
Joined: Dec 16, 2005
Posts: 3089
Location: Bratislava, Slovakia
|
|
|
|
|
|
|
|
Posted: Jul 14, 2012 - 12:30 AM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
|
|
|
|
|
|
Posted: Jul 14, 2012 - 11:24 AM |
|
Joined: Dec 16, 2005
Posts: 3089
Location: Bratislava, Slovakia
|
|
I found that but it appeared to be cold dead... and also the documentation was, ehm... lacking some details... I couldn't get to accept it more than one default path to system includes whereas gcc uses two... it appered to work on manually preprocessed source somehow, though...
Aren't there any usage hints for it?
Thanks,
JW |
|
|
| |
|
|
|
|
|
|
Posted: Jul 14, 2012 - 11:27 AM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
|
|
|
|
|
|
Posted: Jul 14, 2012 - 11:28 AM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
Unfortunately no - I haven't gotten around to using it myself :/
I use Eclipse CDT's Codan feature and CPPCheck myself. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 09, 2012 - 11:49 AM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
|
|
|
|
|
|
Posted: Oct 09, 2012 - 01:28 PM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
This throws an error from the dynamic liner that libiconv-2.dll cannot be found.
In my canadian cross builds for MinGW32 this error does not occur, so is this a misconfiguration from mhv side? |
_________________
avr-gcc News • ABI • Options • 4.8-Windows • Inline Asm
|
| |
|
|
|
|
|
|
Posted: Oct 09, 2012 - 01:34 PM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
| Some multilibs are empty, namely the ./tiny-stack and ./avr25/tiny-stack ones. This means something more went wrong. |
_________________
avr-gcc News • ABI • Options • 4.8-Windows • Inline Asm
|
| |
|
|
|
|
|
|
Posted: Oct 09, 2012 - 01:50 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
Eep, something bad must have happened between building and packaging.
I'll rebuild tomorrow and see if the problem reproduces.
Cheers |
|
|
| |
|
|
|
|
|
|
Posted: Oct 09, 2012 - 02:25 PM |
|
Joined: Jan 01, 2010
Posts: 32
|
|
I just did a clean install and avr-gcc works, and libiconv-2.dll in installed.
If the bin directory is not in the path, you may see this error. If you did not select adding MHV AVR tools to the path at install time, you will either need to launch "MHV AVR Shell", or run the avrvars.bat from the installation in order to set up the path.
I'll need to read up more on the tiny stack issue, but it seems related to:
http://savannah.nongnu.org/bugs/?35407 |
|
|
| |
|
|
|
|
|
|
Posted: Oct 09, 2012 - 06:30 PM |
|
Joined: Dec 21, 2006
Posts: 1489
Location: Saar-Lor-Lux
|
|
I don't set PATH because I have around 20 versions / flavors of foo-gcc. Calling the tools by means of their absolute paths works under Linux and Windows for my builds.
With these builds, it also works if LTO is used which needs liblto_plugin.dll. No setting of PATH is needed.
The difference might be that I prefer --disable-nls with binutils and GCC. Rationale is that if people report problems and they post diagnostics (errors, warnings, fatal messagas, ...) it is not helpful if they are in Klingonian or Elbish or Rongorongo...
AVR-Libc #35407 is work in progress. AVR-Libc does not automatically adopt GCC's multilib layout fromso that each multilib change has to be hand coded in the build machinery. |
_________________
avr-gcc News • ABI • Options • 4.8-Windows • Inline Asm
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
