Update GCC to version 4.6.4, add Linux support

[mupfdev]

In the long run, it would make sense for the compiler to be replaced by one that is somewhat more up-to-date. This would also be interesting for development on *nix-based operating systems.

The latest possible version would be 4.6.4, as support for ARM PE executables was removed in later versions.

Unfortunately, I have not been successful in my previous attempts and could use some help in this regard.

[FtZPetruska]

Okay, over the past few days I've taken a crack at it so here's a breakdown of my approaches and findings.

---

Approach 1 - Reverting the arm-epoc-pe removal

For this approach, I took all the commits in GCC and binutils that aimed to remove the arm-epoc-pe backend, and tried to revert them on the latest release.

While this appeared to work initially, many issues arose when building libgcc. Most notably, the assembler would SEGFAULT when assembling lib1funcs. I suspect the removal of all *-*-pe targets has taken away some glue common to all these backends.

Other limitations/issues I have noticed are:

• No debug information, DWARF2 is not supported, DBXCOFF (what is supposed to be used) had been removed.
• A lot of assembly relies on cfi sections being available, but it's an ELF-exclusive feature.

NB: Reusing libgcc from the existing SDK does not work either.

Approach 2 - Building a newer GCC version before arm-epoc-pe removal

This approach is simple:

• Get the last version of GCC/Binutils that supported arm-epoc-pe as a target
• Try building
• If building fails, try the previous version

The last version supporting arm-epoc-pe are:

• 2.30 for binutils
• 4.6.4 for GCC

Binutils compiled with no issue and seemed to work.

GCC on the other hand did not work at all:

• Version 3 would simply not configure.
• Version 4.6.0-4.6.3 would not configure either.
• Version 4.6.4 would build, but compiling any code would lead to a SEGFAULT.

Most specifically, cc1 hits a SEGFAULT regardless of the mode used:

• -mthumb:

  * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x19)
    frame #0: 0x0000000100c63568 cc1`thumb1_size_rtx_costs(x=0x00000001030ece10, code=SET, outer=SET) at arm.c:7318:23
   7315   
   7316       case SET:
   7317         return (COSTS_N_INSNS (1)
  -> 7318                 + 4 * ((GET_CODE (SET_SRC (x)) == MEM)
   7319                        + GET_CODE (SET_DEST (x)) == MEM));
   7320   
   7321       case CONST_INT:
  Target 0: (cc1) stopped.

• -marm:

  * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x19)
    frame #0: 0x00000001002f72c0 cc1`gen_movsi(operand0=0x000000010241f3c0, operand1=0x0000000000000019) at arm.md:5043:7
   5040         if (GET_CODE (operands[0]) == MEM)
   5041           operands[1] = force_reg (SImode, operands[1]);
   5042         if (arm_general_register_operand (operands[0], SImode)
  -> 5043         && GET_CODE (operands[1]) == CONST_INT
   5044             && !(const_ok_for_arm (INTVAL (operands[1]))
   5045                  || const_ok_for_arm (~INTVAL (operands[1]))))
   5046           {
  Target 0: (cc1) stopped.

I looked around bug trackers and couldn't find anyone discussing similar issues.

I saw a stackoverflow post (that I can't find anymore) suggesting that mpfr (a GCC dependency) was maybe "too new". So I attempted to downgrade it to the recommended 2.4.2 (along the necessary downgrades of gmp and mpc), but it did not solve the issue.

---

So unfortunately, after working on them for a few days, I wasn't able to make either approach work, and I won't have time to keep working on this.

One last note is the following project: https://www.inf.u-szeged.hu/projectdirs/symbian-gcc/index.php

I wasn't able to build it from source on any machine because GCC's config.gcc does not know about x86_64, and makes the assumption that darwin only runs on PowerPC. So while an i386 build should be possible in theory on Windows:

• No support for intel macs, not even 32bits
• even if a 32bits build was made, 64bits Linux and macOS don't run 32bits applications

[mupfdev]

@FtZPetruska Look here, is this helpful in any way?

https://github.com/fedor4ever/GCC4Symbian

[FtZPetruska]

I'm not sure it would. The SDK for the ngage specifically ships with an arm-epoc-pe toolchain, on the other hand, this toolchain targets arm-none-symbianelf (actually, this is still a valid target in GCC and binutils).

This seems to be targeted to more recent Nokia devices running at least armv5 CPUs (ngage runs armv4 afaik).

[mupfdev]

@FtZPetruska managed to compile a toolchain based on GCC 4.6.4, however, it does not work with the SDK yet due to relocation errors when linking. Needs further investigation.