PatchMaker does not link against gcc runtime library (libgcc.a)

[alchzh]

What is the problem? (Here is where you provide a complete Traceback.)

GCC sometimes emits calls to functions stored in libgcc.a. We've run into this occasionally in test cases or when compiling for specific platforms and optimization levels (e.g. PowerPC with CompilerOptimizationLevel.SPACE).

From the GCC documentation:

One of the standard libraries bypassed by -nostdlib and -nodefaultlibs is libgcc.a, a library of internal subroutines which GCC uses to overcome shortcomings of particular machines, or special needs for some languages. (See Interfacing to GCC Output in GNU Compiler Collection (GCC) Internals, for more discussion of libgcc.a.) In most cases, you need libgcc.a even when you want to avoid other standard libraries. In other words, when you specify -nostdlib or -nodefaultlibs you should usually specify -lgcc as well. This ensures that you have no unresolved references to internal GCC library subroutines. (An example of such an internal subroutine is __main, used to ensure C++ constructors are called; see collect2 in GNU Compiler Collection (GCC) Internals.)

This causes errors such as

/workspaces/rbs-ofrak/ofrak/ofrak_patch_maker/ofrak_patch_maker_test/example_1/hello_world.c:5: undefined reference to __mulhi3'`

If you've discovered it, what is the root cause of the problem?

PatchMaker does not link against libgcc.a, and we don't have a mechanism for allocating space for those routines even if we did.

How often does the issue happen?
On specific platforms and optimization levels depending on the code.

What are the steps to reproduce the issue?
Run the patchmaker tests with these stub symbol definitions removed

How would you implement this fix?

Requires a few different changes:

• Adding -lgcc to the end of the linking command (only needed if -nostdlib is used)
• Linking the FEM with the gcc executable instead of ld (otherwise linking will fail in my experience)
• Automatically discovering which symbols are pulled from libgcc.a and making space in the patch for them

Are there any (reasonable) alternative approaches?

Don't fix this, since we can work around it and manually deal with it if its really needed.

Are you interested in implementing it yourself?

Not at the moment, unless it becomes higher priority.