Building Microchip XC32 Compiler

[PuppyEngineer]

Has anyone successfully built the XC32 compilers from the sources on Linux or Windows (MSYS2)?
I've attempted it in order to possibly update it to a newer GCC version for C++, but I get a medley of
failures. Most I've been able to subdue, but it's been a fairly frustrating process so far.

All of this is to update the GCC version from 4.8.3 to something even just a little past that, as
it still uses the TR1 versions of some of the headers with quirks. Stuff like <array> requiring
a heap or some headers requiring RTTI. I've compared a lot of these issues with GCC 7.2 for ARM with
--no-rtti and no heap and it works just fine.

[legacy]

dunno, but you'd best look at some receipt from some distro (e.g. debian) to see which tricks need to be applied

[SiliconWizard]

I tried a couple years ago, and gave up.

Problem is, as far as I know, GCC never included the PIC32 target in the mainline source code, whereas a lot of other targets are part of it. There's probably a good reason. (Funnily enough, I managed to build GCC for the LM32 target (LatticeMico32, Lattice 32-bit soft core) without any problem.)

So anyway, your chances of getting to build XC32 with any other version of GCC than the one Microchip used is close to none (and even with the right version, it's a huge pain to build). And even if it built, the probability of compiler bugs would be very high, so I wouldn't bother.

[westfw]

GCC never included the PIC32 target in the mainline source code

It's a MIPS chip, isn't it?  Some ugly string of modifiers should make a generic MIPS gcc produce usable code?

[technix]

GCC never included the PIC32 target in the mainline source code

It's a MIPS chip, isn't it?  Some ugly string of modifiers should make a generic MIPS gcc produce usable code?

Technically, yes. In reality, you would need the linker scripts from Microchip that matches the memory configuration. Otherwise it is mostly choosing the processor core and FPU.

[andersm]

You may need to disable warnings as errors when configuring. Newer compilers issue a lot of warnings for older versions of GCC (and Microchip's own additions are definitely not warning clean). Also have a look at the chipKIT build script.

[andersm]

It's a MIPS chip, isn't it?  Some ugly string of modifiers should make a generic MIPS gcc produce usable code?

Yes, as long as you don't need to be source or binary compatible with XC32.

[ale500]

The chipkit gcc, that do not have the optimization limitations produces compatible libs and objects.
I also tried several times to compile it in different environments, cygwin or mingw without success. Even using the chipkit compilation script. It probably depends on a very specific compiler version... maybe disabling warnings works... I never tried again. You only need cc1...

[legacy]

GCC never included the PIC32 target in the mainline source code

It's a MIPS chip, isn't it?  Some ugly string of modifiers should make a generic MIPS gcc produce usable code?

no

patches need to be applied

[legacy]

You only need cc1...

"cc1" translates from C to assembly. It's output is a .s file. You need "gcc" and "collect2" (as well as cpp) to fully handle linker scripts and the proper flags passed to the toolchains' item (as, ld, blablbla).

"gcc" is required, unless you want to create your own wrappers, and you need to be aligned with them for the Microchip's debugger.

[legacy]

Also, sometimes, you need to patch binutils as well as gcc (and not even to force gcc to use the proper flag when it invokes an tool in the toolchain, quite rather) in order to fully support hardware differences, e.g. you can use a vanilla gcc neither for Chinese's MIPS64-le nor for Calvium's MIPS64-be, since they are both not exactly compatible from the machine-layer point of view to what is provided out of the box by GNU. In this case they are claimed to be "MIPS64", but they don't fully respect the ISA.

[SiliconWizard]

GCC never included the PIC32 target in the mainline source code

It's a MIPS chip, isn't it?  Some ugly string of modifiers should make a generic MIPS gcc produce usable code?

Well, PIC32 are based on MIPS32 cores, indeed. The PIC32MX are based on MIPS32-M4K to be exact.

GCC can compile code for MIPS32-M4K targets by using a GCC where MIPS targets are enabled, with the flag

Code: [Select]

-march=m4k on the command line.
(See: https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/MIPS-Options.html#MIPS-Options )

XC32 adds the option

Code: [Select]

-mprocessor=xxx to replace

Code: [Select]

-march=yyy, which enables additionnal support for the specifics of PIC32, which you won't have with a plain GCC targeting MIPS.

You wouldn't be able to use the Microchip support header files nor any Microchip libraries. XC32 adds extensions to GCC, such as some builtin functions and probably a lot of other stuff. You'd have to write your own header files, startup code and so on, and I don't even know whether Microchip added instructions to the MIPS instruction set or not. You'd have to look at the XC32 source code extensively to get an idea. The vanilla linker may also not produce proper object code for the PIC32. And then you'd end up with tools you would have a hard time trusting anyway...