AXF file format changed with LPCXpresso v8.1.0

[lpcware]

Content originally posted in LPCWare by robert hulsebos on Fri Mar 04 03:01:35 MST 2016
We have a own-developed tool that parses the .axf output file that LPCXpresso generates for a LPC1769 MCU. Currently our engineers are using LPCXpresso v7.9.2. I am evaluating transition to v8.1.0. One of the things I noticed during the test drive with this latest version is that with the new LPCXpresso our tool generates errors on the .axf file. Has the format of the .axf file changed since v7.9.2 ?

[lpcware]

bump

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Mar 24 01:38:56 MST 2016
This alignment behaviour with GCC/LD, when an image is built to a, IIRC, non-64KB aligned address has been required for as long as I can remember (at least 5 or 6 years, and probably much longer). I believe it has something to do with MMU and page tables under Linux, which is of course is where much of the GCC tools work originated.

I have no idea why you should therefore be seeing different behaviour in LPCXpresso IDE v8.1. I haven't seen any differences here, and I can only assume that it is some subtle change in the latest GCC/LD that is being triggered by something specific in your application.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by robert hulsebos on Wed Mar 23 09:59:26 MST 2016
Thanks! This seems to work...
I looked up the -n option in LD docs:

-n
--nmagic
    Turn off page alignment of sections, and disable linking against shared libraries. If the output format supports Unix style magic numbers, mark the output as NMAGIC.



So it was an alignment issue... Am I correct in assuming that the default setting for this has changed since LPCXpresso v7.9.2 ? Or is this something that came with a newer version of the GNU toolchain?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Mar 07 09:15:36 MST 2016
Try adding the "-n" linker option to the "Other options" entry of:

Project - Properties - C/C++ Build - Settings - MCU Linker - Miscellaneous

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by robert hulsebos on Fri Mar 04 10:19:23 MST 2016
Hi Mike,

Thanks for your suggestion. I am familiar with the ELF format - I used the spec for developing the initial version of the tool.

I dug into it and found the ELF header is still the same. The problem seems to be in the first Program Header. Our application is linked for address 0x8000. Our tool uses p_offset and p_filesz fields of the Program Header to determine the start and size of the segment. They were OK before with values as expected. With LPCXpresso v8.1.0 field p_offset has value zero and the p_filesz field has a value that is exactly 0x8000 bytes too long. Hmmm... 
Especially the fact that p_offset has value zero is 'weird' as it is defined by the spec as follows: 'This member gives the offset from the beginning of the file at which the first byte of the segment resides'; so offset zero would refer to first byte of ELF header...which cannot be right ...

Additional info: The problems seems to be caused by the start address for linking;a faulty .axf is generated when I build the application - it must start in the MCU memory map at address 0x8000. When I build the bootloader, which is to start in the MCU memory map at address zero, a correct .axf is generated.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Fri Mar 04 03:07:08 MST 2016
As you know, the axf is simply another name (WHY?!!) for elf.

The elf specs are widely availably on the ARM-INFO site and generally on the internet.
We are not using 8 at the moment, however ...

8 uses GCC 5 whereas before that it was GCC 4.
Check the version/revision field in the elf header to see if a new format is being used;
if so read the latest specifications.

Cheers, Mike.