Building also Cortex-A and big-endian Cortex-R / Restart build

[42Bastian]

Building also Cortex-A and big-endian Cortex-R / Restart build

[dobryj]

We have same motivation - TMS570.
Tip: Due to problems with GCC8&GCC9 we are still use package ARM GCC 7 2018q2 . Patch is here https://pastebin.com/RcdDaydf

[dobryj]

I am trying to compile latest 9.1.0 but with old binutils (2.30). Still waiting for compilation, I will report result.
PS: We are waiting for BE support till GCC4.6. It is looooong time. Problem was zero goodwill from ARM guys (maintainers of ARM GCC) to accept code which can't be tested on theirs side.

[dobryj]

GCC 9.1.0 with my patch:
arm-none-eabi-g++ --print-multi-lib
.;
arm/v5te/softfp;@marm@march=armv5te+fp@mfloat-abi=softfp
arm/v5te/hard;@marm@march=armv5te+fp@mfloat-abi=hard
thumb/nofp;@mthumb@mfloat-abi=soft
thumb/v7/nofp;@mthumb@march=armv7@mfloat-abi=soft
thumb/v7/nofp/be;@mthumb@march=armv7@mfloat-abi=soft@mbig-endian
thumb/v7+fp/softfp;@mthumb@march=armv7+fp@mfloat-abi=softfp
thumb/v7+fp/hard;@mthumb@march=armv7+fp@mfloat-abi=hard
thumb/v7+fp/softfp/be;@mthumb@march=armv7+fp@mfloat-abi=softfp@mbig-endian
thumb/v7+fp/hard/be;@mthumb@march=armv7+fp@mfloat-abi=hard@mbig-endian
thumb/v6-m/nofp;@mthumb@march=armv6s-m@mfloat-abi=soft
thumb/v7-m/nofp;@mthumb@march=armv7-m@mfloat-abi=soft
thumb/v7e-m/nofp;@mthumb@march=armv7e-m@mfloat-abi=soft
thumb/v7e-m+fp/softfp;@mthumb@march=armv7e-m+fp@mfloat-abi=softfp
thumb/v7e-m+fp/hard;@mthumb@march=armv7e-m+fp@mfloat-abi=hard
thumb/v7e-m+dp/softfp;@mthumb@march=armv7e-m+fp.dp@mfloat-abi=softfp
thumb/v7e-m+dp/hard;@mthumb@march=armv7e-m+fp.dp@mfloat-abi=hard
thumb/v8-m.base/nofp;@mthumb@march=armv8-m.base@mfloat-abi=soft
thumb/v8-m.main/nofp;@mthumb@march=armv8-m.main@mfloat-abi=soft
thumb/v8-m.main+fp/softfp;@mthumb@march=armv8-m.main+fp@mfloat-abi=softfp
thumb/v8-m.main+fp/hard;@mthumb@march=armv8-m.main+fp@mfloat-abi=hard
thumb/v8-m.main+dp/softfp;@mthumb@march=armv8-m.main+fp.dp@mfloat-abi=softfp
thumb/v8-m.main+dp/hard;@mthumb@march=armv8-m.main+fp.dp@mfloat-abi=hard

[42Bastian]

gcc 7.4.0 with your patch and binutils 2.32 gives a correct ELF. But just tried a minimal one with your settings on launchpad.net
So maybe it is the combo gcc 9.1.0 and binutils 2.32?!

[dobryj]

EUREKA!
I solve problem with instructions endianity. Problem is endian behavior changed in GCC8:
"The default link behavior for Armv6 and Armv7-R targets has been changed to produce BE8 format when generating big-endian images. A new flag -mbe32 can be used to force the linker to produce legacy BE32 format images. There is no change of behavior for Armv6-M and other Armv7 or later targets: these already defaulted to BE8 format. This change brings GCC into alignment with other compilers for the ARM architecture."

This command produce correct code:
arm-none-eabi-g++ -o test.elf -mcpu=cortex-r5 -mthumb -T empty.ld -Wl,--gc-sections test.c -mbe32 -mbig-endian

Tested on silicon. It works!

EDIT: Differences between BE-32 and BE-8

[FreddieChopin]

Do you have a hint how to build for all Cortex-M/R/A and big-endian. I see you use mrprofile? Can one add additional profiles?

I don't think you can use multiple profiles at once, but I suspect that you could change the profile to something else if you like.

Sometime ago there was support for building also big-endian variants of the library, commited by @dobryj See the commits:
https://github.com/FreddieChopin/bleeding-edge-toolchain/commits?author=dobryj
However due to changes in gcc itself (introduction of rmprofile, with different structure) I had to remove it.

If you would like to add that back, then it is only a matter of creating an inline patch for the rmprofile which would also have big-endian variants.

I see no way to restart a build. It always starts all over (at least not downloading).
Did I miss it?

Currently the script does not support resuming and it does start from scratch every time. However see #18 which I hope to merge soon, which will bring experimental support for resuming.

[42Bastian]

Hi
it drives me crazy. It just seems to ignore my changes to t-multilib. I just added this line:
MULTILIB_OPTIONS += mbig-endian
MULTILIB_DIRNAMES += eb
and the corresponding "MULITLIB_REQUIRED" lines.
Regarding: "restarting", I added some "if [ 0 = 1 ]; then" lines, to exclude building, cleaning everything.
It also seems, other "t-*" are broken. I tried t-rtems as option, but it does not work.
I hope I can find a patch somehow.

[FreddieChopin]

it drives me crazy. It just seems to ignore my changes to t-multilib

I assume you are trying to use the latest script from master branch. In that case the file that is used is this one - https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/arm/t-rmprofile?revision=267494&view=markup

Additionally you have to either use an inline patch in the script or modify it in some other way (or prepare a changed gcc package) - otherwise the script always starts from scratch, which means it will overwrite any local changes you make to the gcc sources.

Let me know how can I help you, but I'm not really an expert on these cryptic profile files (;

[42Bastian]

I changed the script, so that I skip all step until buildGcc. There I copy my t-multilib into the source folder.
There must be one tiny thing :(
I replaced the t-multilib contents with the t-rtems one and - yeah - --print-multi-lib shows big endian paths. But then, newlib does not build :( => back to start

[42Bastian]

Let me know how can I help you, but I'm not really an expert on these cryptic profile files (;

I will talk to my boss @ SCIOPTA, maybe you can really help.

[FreddieChopin]

I changed the script, so that I skip all step until buildGcc. There I copy my t-multilib into the source folder.
There must be one tiny thing :(

Which version of the script are you using? The one which did support big-endian stuff or the current master?

[42Bastian]

The current one. We have a customer who wants to use the latest GCC.

[FreddieChopin]

In current GCC (since GCC 7) if you use --with-multilib-list=rmprofile (as in the script here), then the file which is used is not t-multilib, but t-rmprofile (from the same folder).

[42Bastian]

Actually it is. t-multilib includes t-rmprofile and t-aprofile (if in the list).
I checked by adding a $(error t-multilib) in that file.

[FreddieChopin]

Sorry for the noise then (;

[42Bastian]

No problem. Any hint is welcome. Luckily I can try it on an 8 core machine, so compiling does not take to long ...

[dobryj]

If you want to compile it include bigendian , you can use this patch: https://pastebin.com/Y8JNi45J
Content of file armgcc_BE_9.1.0.patch is here https://pastebin.com/mzm12Q8m

At this moment support of bigendian on GCC8 and GCC9 is little bit problematic. Reason is full support of needed features (multilib) in GCC8+. Therefore it is teoretically possible to push needed changes to GCC main trunk. But I can't do it before solution of this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163

[42Bastian]

dobryj, your t-multilib looks pretty much like mine. But not 100%. I give yours a try.
BTW: I need it for the same reason: TMS570. I wonder why on earth TI decided to make it big-endian.

[dobryj]

Code produced by GCC 9.1.0 don't run on TI TMS570. I don't know reason at this moment.
Code pruduced by GCC 8.3.1 not works to. (package ARM GCC 8-2019-q3-update with my bigendian patch same as for 9.1.0)

EDIT: update GCC 8.3.1 result

[42Bastian]

Thanks for the hint and pre-build.

[dobryj]

This is not pre-build. This link is to source code provided by ARM and link to my patch.

[42Bastian]

I see.

[42Bastian]

Jiri, using your patch and the Freddie's script, I could build 7.4.0 with v7-ra/be. Now I need to test ;-)
The 9.1.0 build with your patch had some weird combinations in the multi-libs and seems to be wrong.
Like "be" folder, but not the big-endian option.

[dobryj]

It looks, that problem is on binutils used by GCC8 and GCC9. It broke instruction endianity.
https://answers.launchpad.net/gcc-arm-embedded/+question/682041

[42Bastian]

So this would mean, the build I did now using the current master script should fail as well. As I build gcc 7.4.0 with the latest binutils.
It is really a shame that no official support for big-endian Cortex-R was added since Hercules exists. I patched gcc 5.2 loooooong time ago.

[42Bastian]

That's a pity. One should think that ARM has plenty of targets which can run big-endian. The commercial compilers can also build big-endian code. Sad story.

Edit:
Did you check the result of --print-multi-lib? No weird combinations?

[dobryj]

ARM GCC 7 2017-q4-major (with my patch, 100% working version)
arm-none-eabi-g++ --print-multi-lib
.;
thumb;@mthumb
hard;@mfloat-abi=hard
thumb/v6-m;@mthumb@march=armv6s-m
thumb/v7-m;@mthumb@march=armv7-m
thumb/v7e-m;@mthumb@march=armv7e-m
thumb/v7-ar;@mthumb@march=armv7
thumb/v8-m.base;@mthumb@march=armv8-m.base
thumb/v8-m.main;@mthumb@march=armv8-m.main
thumb/v7e-m/fpv4-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=softfp
thumb/v7e-m/fpv4-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=hard
thumb/v7e-m/fpv5/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=softfp
thumb/v7e-m/fpv5/hard;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=hard
thumb/v7-ar/be;@mthumb@march=armv7@mbig-endian
thumb/v7-ar/fpv3/softfp;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=softfp
thumb/v7-ar/fpv3/hard;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=hard
thumb/v7-ar/fpv3/softfp/be;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=softfp@mbig-endian
thumb/v7-ar/fpv3/hard/be;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=hard@mbig-endian
thumb/v8-m.main/fpv5-sp/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=softfp
thumb/v8-m.main/fpv5-sp/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=hard
thumb/v8-m.main/fpv5/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=softfp
thumb/v8-m.main/fpv5/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=hard

[dobryj]

We can also try to modify little endian path in multilib library. I prefer to not modify remaining part of multilib (like as GCC7) but i could be mistake.
Pair like thumb/v7+fp/hard/le + thumb/v7+fp/hard/be could be better than current thumb/v7+fp/hard + thumb/v7+fp/hard/be

[dobryj]

Did you read reaction on launchpad? It is apprehensible and expected reaction.

[42Bastian]

script from master, GCC 7.4.0 + DobryJ's endian-patch works an TMS570LC43 (on Windows)

Edit: -flto does not work!
c:/compiler/gcc/arm-none-eabi-gcc-7.4.0-190715/bin/../lib/gcc/arm-none-eabi/7.4.0/../../../../arm-none-eabi/bin/ld.exe: error: could not unlink output file

[dobryj]

See to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
Your LTO result is surprice, because I was idea about dependency of this problem to GCC8+. We don't have any LTO related problem with (BE patched) ARM GCC 7-2018-q2-update (Based on GCC 7.3.1 (embedded-7-branch revision 261907); binutils 2.30; etc. see release notes for 7-2018-q2-update, direct link is not possible

[dobryj]

GCC 9.1.0 + binutils 2.30 does produce invalid code for BE (as expected, because your combination 7.4.0 + 2.32 is OK)

[dobryj]

Bastian, by my observation LTO "unlink" problem is related to windows binaries. Linux version of compiler is OK. Can you confirm it on your combination?
For ex on this command:
arm-none-eabi-g++ -o test.elf -mcpu=cortex-r5 -mthumb -T empty.ld -Wl,--gc-sections test.c -mbig-endian -flto

[dobryj]

"LTO unlink" problem depend to binutils version.
GCC 9.1.0 + binutils 2.30 is OK
GCC 9.1.0 + binutils 2.32 failing with " error: could not unlink output file"

[Trass3r]

Did you use -g?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90369

[dobryj]

Yes, we are using -g, but not -save-temps which is second condition for bug PR90369.
This must be another bug. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163

[42Bastian]

"LTO unlink" problem depend to binutils version.
GCC 9.1.0 + binutils 2.30 is OK
GCC 9.1.0 + binutils 2.32 failing with " error: could not unlink output file"

Same here. Linux works. Windows bails out. But the ELF is built.

[dobryj]

GCC 9.1.0 + binutils 2.31 failing with " error: could not unlink output file"
I will try tu use latest binutils code from GIT. I found many changes reated to endianity.
For ex 1 or 2

[dobryj]

I try latest binutils (commit 07128006d6caec5df31a960b131d2026f35ed948)

Here fast&dirty workaround to compile it together.
https://pastebin.com/6XQF2wV0

You need clone binutils to your home directory git clone git://sourceware.org/git/binutils-gdb.git

I made just first test, but it looks OK (include LTO).

EDIT: update pastebin link.

[42Bastian]

I decided to stick with 2.30 rather then using an unstable version and forked.