objcopy.exe: 64-bit address 0x4b4fa300000000 out of range for Intel Hex file

[Leo Havmøller]

New in 8 2018-q4-major, OK in previous versions.
When extracting code from .elf, objcopy reports "64-bit address 0x4b4fa300000000 out of range for Intel Hex file".

Commands:
D:\gcc>"C:\Program Files (x86)\GNU Tools ARM Embedded\8 2018-q4-major\bin\arm-none-eabi-gcc.exe" -c -Os -mcpu=cortex-m0 -mthumb -Wall -Wextra -Wlogical-op test.c -o test.o

D:\gcc>"C:\Program Files (x86)\GNU Tools ARM Embedded\8 2018-q4-major\bin\arm-none-eabi-objcopy.exe" -O ihex test.o test.hex
C:\Program Files (x86)\GNU Tools ARM Embedded\8 2018-q4-major\bin\arm-none-eabi-objcopy.exe: test.hex 64-bit address 0x4b4fa300000000 out of range for Intel Hex file
C:\Program Files (x86)\GNU Tools ARM Embedded\8 2018-q4-major\bin\arm-none-eabi-objcopy.exe:test.hex: bad value

Minimal example attached.

[Sebastian Bøe (sebastianbooe)]

It seems that this affects the Windows build, but not the Linux build.

Perhaps something to do with how the toolchain was built for Windows?

[Edwin Hoeks (ehoeks)]

Temporary workaround

Using 8 2018-q4-major on Atmel Studio 7 on Windows results in the same issue.

As a workaround I created a '8 2018-q4-major-fix' folder that is a copy of '8 2018-q4-major' with the arm-none-eabi-objcopy of '7 2018-q2-update' this seems to work (but more testing is needed)

[Edwin Hoeks (ehoeks)]

An alternative source for high quality gnu gcc embedded arm compiler packages is: gnu-mcu-eclipse

His (https://github.com/ilg-ul) build based on the sources of 8-2018-q4-major does not have the problem and is a drop in replacement of the 'official' ARM build

https://gnu-mcu-eclipse.github.io/toolchain/arm/
https://gnu-mcu-eclipse.github.io/blog/2019/01/03/arm-none-eabi-gcc-v8-2-1-1-1-released/

[Freihofer (martin605)]

The toolchain from 'https://gnu-mcu-eclipse.github.io/blog/2019/01/03/arm-none-eabi-gcc-v8-2-1-1-1-released/' produces the same error.

A manual copy from version 7 seems to work, but I would not trust this workaround, as long as no one knows the pitfalls behind!

[Liviu Ionescu (ilg)]

> C:\Program Files (x86)\GNU Tools ARM Embedded\8 2018-q4-major\bin\arm-none-eabi-objcopy.exe: test.hex 64-bit address 0x4b4fa300000000 out of range for Intel Hex file

the '(x86)' in the path makes me think the problem occured in a 32-bit application.

the '64-bit' in the message makes me think the address is a wide one.

in other words, it might be possible that objcopy thinks of himself as being a 64-bit app even when running on a 32-bit target.

if so, the 64-bit build of the toolchain might be ok, and only the 32-bit be affected.

can someone test both the 32-bit and the 64-bit and compare the results?

[Liviu Ionescu (ilg)]

I did a new test on a 64-bit Win 10 virtual machine, and it confirms my hypothesis, the 64-bit build of MCU Eclipse ARM GCC works:

Invoking: GNU ARM Cross Create Flash Image
arm-none-eabi-objcopy -O ihex "f4b.elf" "f4b.hex"
Finished building: f4b.hex

while, on the same 64-bit machine, the 32-bit build of MCU Eclipse ARM GCC fails:

Invoking: GNU ARM Cross Create Flash Image
arm-none-eabi-objcopy -O ihex "f4b.elf" "f4b.hex"
arm-none-eabi-objcopy: f4b.hex 64-bit address 0x4a2a7708000000 out of range for Intel Hex file
arm-none-eabi-objcopy:f4b.hex: bad value
make: *** [makefile:70: f4b.hex] Error 1

I also tested the 64-bit Linux build on a 64-bit Ubuntu 16LTS virtual machine, and it was ok:

Invoking: GNU ARM Cross Create Flash Image
arm-none-eabi-objcopy -O ihex "f4b.elf" "f4b.hex"
Finished building: f4b.hex

it would be interresting if someone could test the 32-bit Linux build, I don't have one at hand.

[Andrey B (arro239)]

Speaking of which, why is launchpad not offering 64 bit windows binaries at all? in the year of 2019 is not that a bit weird?

[Andrey B (arro239)]

We have a report that gcc 8.2.1 from August build is NOT affected. Complete version line of NOT affected version:

gcc version 8.2.1 20180802 (GNU Toolchain for the A-profile Architecture 8.2-2018.11 (arm-rel-8.26))

[Peter Wessel (piwi1263)]

Hi All,

we at the nanoFramework team do seem to suffer from this <what-ever-it-is> behavior too.

While using the 8 version we first got a complaint about a deprecated -mstructure-size-boundary=8 and of course had to remove that option. Doing a new compile without that option resulted in the same behavior.

[build] C:\dev\tools\arm_gcc\821\bin\arm-none-eabi-objcopy: C:/dev/github/nf-interpreter/build/nanoBooter.hex 64-bit address 0x4b4fa308000000 out of range for Intel Hex file
[build] C:\dev\tools\arm_gcc\821\bin\arm-none-eabi-objcopy:C:/dev/github/nf-interpreter/build/nanoBooter.hex: bad value

Doing the same work around as mentioned above by Edwin Hoeks fixed the objcopy behavior.

This too is running on a 64-bit windows 10 system.

In case you require more info the complete log is to be found here https://github.com/nanoframework/Home/issues/443

[Liviu Ionescu (ilg)]

I also tested on a 32-bit Linux virtual machine, and the behaviour is the same, objcopy fails with something like '64-bit address 0x4a2a7708000000 out of range for Intel Hex file'.

The conclusion is the same as presented before, the latest binutils have a problem when building on 32-bit machines.

For the moment, the quick workaround is to manually override the binary with one from the previous release, but this does not work for automated CI environments which use pre-packaged releases (like my xPacks).

[Liviu Ionescu (ilg)]

https://sourceware.org/bugzilla/show_bug.cgi?id=24065

[Liviu Ionescu (ilg)]

The bug upstream was fixed, now all is needed is a new Arm release to include this fix.

[Leo Havmøller (leh-p)]

The next schedule release is 9-2019-q4-major, expected 2019-12-31.
Was there ever an out of schedule bugfix release of GNU Arm Embedded Toolchain?

[Liviu Ionescu (ilg)]

In the mean time those interrested on a fixed toolchain can use the GNU MCU Eclispe binaries:

https://github.com/gnu-mcu-eclipse/arm-none-eabi-gcc/releases/tag/v8.2.1-1.2

To avoid any compatibility issues, I used exactly the same sources, but applied the binutils patch.

[Edwin Hoeks (ehoeks)]

Thanks Liviu,

Hopefully nanoframework and ARM follow soon. Until that time, 'free' advertisement for your project.

Regards,

Edwin Hoeks

[Liviu Ionescu (ilg)]

great!

I'll prepare a new release following yours.

thank you,

Liviu