Linking code from GCC into Green Hills project

[CurtM]

My company has existing C code to control our products that one of our customers would like to build into their own application, running on their electronics that use an MPC567xK.

It's basically stand-alone: they'd call 1 big function to calculate stuff. Minimal math.h dependencies, and I might even replace those with lookup tables.

They use Green Hills. I'd like to use NXP's GCC package.

Is it feasible for me to build an object file to hand over to them? (maybe I'd need a linker script to change some sections? maybe statically link libgcc?)

[CurtM]

Luckily, it's all C, not C++.

OK. I saw some Green Hills and Red Hat names in the PowerPC EABI specification, so I guess that gave me some hope that EABI was implemented by Green Hills for embedded Power/PowerPC targets.

[petervlna]

Hello,

It will require some effort but it is feasible:

Key Considerations:

1. ABI Compatibility

• GCC and Green Hills use different ABIs (Application Binary Interfaces), especially for Power Architecture (used in MPC567xK).
• This means object files (.o) or static libraries (.a) compiled with GCC may not be directly usable in a Green Hills environment.
• Solution: Instead of handing over object files, consider providing a C source file or a well-documented API if possible. If binary-only distribution is required, consider building a static library with strict ABI alignment, or even a separate firmware module.

2. Linker Script

• If you must provide a binary, you’ll likely need a custom linker script to:
  • Place sections correctly (e.g., .text, .data, .bss)
  • Avoid conflicts with the customer's memory map
  • Ensure alignment and section naming conventions match Green Hills expectations

3. Static Linking of libgcc

• If your code uses GCC-specific runtime features (e.g., division routines, __aeabi_* functions), you should statically link libgcc to avoid missing symbols.
  • Use: -static-libgcc when compiling
  • You might also need to include other runtime support libraries depending on your math usage

4. Math Dependencies

• Replacing math.h functions with lookup tables or custom implementations is a good idea to avoid linking issues.
• Especially for functions like sin, cos, sqrt, which may pull in floating-point libraries or libm.

5. Calling Convention

• Ensure your function uses a C-compatible calling convention (extern "C" if using C++).
• Avoid compiler-specific attributes unless absolutely necessary.

6. Testing

• Provide a test harness or simulation environment to validate the integration.
• If possible, test your compiled binary in a Green Hills environment using a simple wrapper.

Best regards,

Peter