Need "Howto" to re-build GCC for Arduino 1.8.4 on Windows XP

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First, Windows XP is fixed as my IDE execution environment; this can not be changed. 

 

Second, I'm having problems with the Arduino IDE -- it program checks (bad pointer) inside GCC (actually ld from binutils) while building my sketch. 

 

The task is to try and debug the GCC included with the Arduino IDE.  As the IDE distribution has removed symbols and debug information, analyzing the windows dump is virtually impossible.

 

To make further progress, it appears that GCC (binutils and GCC) need to be rebuilt from the same source the IDE people used.

 

Then the new build has to be overlayed on (inserted into) the IDE libraries. 

 

Finally, set windows debugging to trap the memory access error, start the IDE and compile the sketch, the save a dump when the program exception occurs.  At that point, there should be enough debug information to figure out the dump, I hope, I hope.

 

(If there's an alternative method recommended, perhaps have the IDE starting the GCC debugger to do the compile, please speak up.)

 

I don't know what the IDE people used as the build system.  I've heard linux, and mingw (the old one, not mingw2).  Ubuntu is available for re-building, but the host must be Windows XP.  The target, of course, is arm.

 

About a year ago, I tried building GCC with (most?) Arduino patches and got hung up getting a successful C++ build.  'binutils' appeared to build OK, but it was not sufficient to substitute just the binutils modules back into the IDE library.  I assume that both binutils and gcc must be built together in order to successfully work together.

 

1.  I need the GCC source (i.e. the version Arduino used) which I can locate and download (once I know what release).

 

2.  I need all the Arduino patches for GCC.  I understand they come from two places: Atmel (Microchip) and Arduino.   I don't know where to download current patches.

 

3.  I need a build script(s).  I've seen several, none of which worked 100% in a cygwin, MinGW, or MinGW-64 environment.  Where can  I download the one used by Arduino, and what is their build environment?

 

I can (and have) gotten Xbuntu, cygwin, MinGW, and MinGW-64 running.  I've fetched and build packages like GMP.  I've written bash scripts, and done windows development.  My background is software development for a dozen different machine and software architectures. 

 

This should not be beyond me, but I need to be working with the same beast as the Arduino IDE people have unleashed.

 

Thanks for any leads you can give me; I've no problem doing leg work.

Last Edited: Mon. Sep 25, 2017 - 09:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JMThomas wrote:
I'm having problems with the Arduino IDE

So have you posted in the Arduino forums?

 

EDIT

 

By which I mean: https://forum.arduino.cc/

 

This one looks a likely candidate:

 

Other Software Development

 

Mods to the IDE, suggestions for the core code to the boards, better bootloaders, new libraries
 

https://forum.arduino.cc/index.p...

Last Edited: Mon. Sep 25, 2017 - 09:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got my log from last year and started looking where I'd looked in the past.

 

The problem I was having, reported on github arduino/#2998, may have been fixed

 

The build instructions have been updated.  Now building on windows uses cygwin and WinMG built for/included by cygwin.  Note that installing cygwin on XP is impossible without fetching it from the cygwin archive -- see this stack exchange item.

 

At this point, I'm verifying the fix is good for my sketches.  I may not have to debug avr-gcc!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

So have you posted in the Arduino forums?

 

EDIT

 

By which I mean: https://forum.arduino.cc/

 

This one looks a likely candidate:

 

Other Software Development

 

Mods to the IDE, suggestions for the core code to the boards, better bootloaders, new libraries
 

https://forum.arduino.cc/index.p...

 

The Arduino people were not any help.  Nobody there was familiar with Gcc or the AVR tool chain.  There were lots of complaints about the compile fail problem I was having, but no one had anything to say other than to try tweaking the source until the compiler stopped program checking.

 

I did have a brief conversation with a developer (via github) who gave me a fix to test.  It didn't work.  He did get an example that would finally fail on his machine.

 

Following the instructions posted on github (per developer) at  the time to build avrtools failed.  It's like they never built on a windows host.  No further support was provided by the developers when I reported the build problems.

Last Edited: Mon. Sep 25, 2017 - 11:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just an idea:

 

Have you tried importing your sketch(es) into Atmel Studio, to see if it will build them OK? Or if it has the same problem?

 

There are certainly people here who know the internals of the AVR-GCC used by Studio ...

(but I am not one of them).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe you can get some info from this: http://blog.zakkemble.co.uk/avr-...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

https://github.com/arduino/toolc... isn't helpful?

 

I thought:

1) The "ld crashes in WXP" bug had been fixed.

2) Prior to that patch, the recommended solution was to steal ld.exe from an older version of the IDE.

3) The only reason that the compiler has been updated is to keep up with atmel, especially WRT new chips.

4) Otherwise, you would probably be OK copying an complete other toolchain (from atmel or an older IDE) (not that I've tried it.)

5) (oh.  Also LTO.  There's an LTO patch in there.  It might be easiest to just turn off LTO.)

 

 

The Arduino people were not any help.  Nobody there was familiar with Gcc or the AVR tool chain.

 It's not surprising that no one there is familiar with building the toolchain, but ... I didn't see your question go by recently, and I'm sure I've see the "older ld.exe" solution, and the more recent actual fix mentioned...  And someone should have been able to point you to the above github link!

 

 

Note that installing cygwin on XP is impossible without fetching it from the cygwin archive

And that surprises you?  Having anything supported on XP is going to be increasingly difficult, outside of running "old version of x, using old version of y library and z utility."

Can you potentially do the build on a newer box?  (one that supports current cygwin)

 

Do you have a sample sketch that fails?  I've upgraded most of my windows boxes and VMs beyond XP, but there are still a few around and I could give it a try.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. Find out which tool is crashing.  If it's ld then you don't need to (re) build the compiler.

 

2. Get a command-line reproducer, i.e. without obfuscating and disturbing IDE.  Add -v, -Wl,-v -save-temps o the command line options to yield the invokation that crashes.  If you specify the printed options and the intermediate files as indicated by -v, the tool should still crash outside the IDE / Makefile / whatever.

 

3. If it's a memory allocation issue, then whether or not the tool crashes for specific invocation might depend on history and host OS.  If the bug is "stable", then you should be able to reproduce it under a different host OS like linux.  It's way less painful to build and debug the tools for and under linux.

 

4. Try to minimize the reproducer, e.g. cope with less functions, modules (*.o), libraries (*.a) in the ld invocation. If the linker errors because a symbol foo is missing, you can --defsym foo=0 to silence the linker and make it pass.

 

ad 2:  Ask the arduino guys where and how to add these options to the relevant tool invocations.

 

ad 3: There are other cases where reproducability depends on host OS.  One example is qsort behaviour of host libc if two elements compare equal.

avrfreaks does not support Opera. Profile inactive.