#107 GCC port.c: turn off lto before assembly sections + patch

[IvanSB]

In large projects you may have lto turned on globally (or simply set by your IDE du jour) this causes "undefined reference" errors in port.c (https://gcc.gnu.org/wiki/LinkTimeOptimizationFAQ).
This problem can be solved wrapping the assembly code in

#pragma GCC push_options
#pragma GCC optimize ("no-lto")

// code

#pragma GCC pop_options

thanks

[Richard Barry]

Which port are you referring to? There are lots of GCC ports.

[IvanSB]

Hi,

all the ones that contain asm code, and most do.
grep __asm volatile may help to find them all.

The one I'm personally interested into are GCC/ARM_*, the one that is actually giving problems is ARM_CM3, but I bet others suffer the same nuisance.

thanks for your interest

[Richard Barry]

Does this also effect macros and/or inline functions that include asm code defined in portmacro.h? As they are included in lots of C files.

[IvanSB]

The problem arise where functions and variables defined in C are used in asm.

I had problems with pxCurrentTCB and vTaskSwitchContext (defined in tasks.c and used in port.c).

In the GCC ARM CM3 port portmacro.h is not an issue but I think ARM7_AT91FR40008/portmacro.h could be as many other portmacro.h if they refer to C functions or variables. eg. ulCriticalNesting is another candidate to cause undefined reference errors.

Right now I can't think of a correct regex to find all the problematic asm that should be wrapped, but at least for ARM I'd look to
bl instructions and to all load function followed by =variable.

At first glance this is not going to cover all the ARM cases eg.

__asm volatile( "mrs %0, ipsr" : "=r"( ulCurrentInterrupt ) );

could be problematic as well.

Similar strategy may be used to spot potential problems in other architectures.

Maybe a deeper understanding of FreeRTOS may help just knowing the list of variables and functions that may be called in asm and looking for them in spite of coming up with a smart regex.

Sincerely I'm just using the ARM CM3 port and I haven't had the time to get a global picture of the problem.

thanks for keep following the issue

[Erich Styger]

Hello,
I have run only into one problem with -lto.
I have solved it in this way in task.h

#ifdef GNUC /* << EST: 'used' attribute need for LTO (Link Time Optimization) */
  void vTaskSwitchContext( void ) PRIVILEGED_FUNCTION __attribute__((used));
#else
  void vTaskSwitchContext( void ) PRIVILEGED_FUNCTION;
#endif

I hope this helps,
Erich

[Richard Barry]

I'm having trouble replicating this issue.

I have a Cortex-M4F GCC project from FreeRTOS V9.0.0rc2 which builds cleanly. I then add -flto to both the compile and link phase command line options, and it still builds correctly :o( How can I replicate the error?

[IvanSB]

I remember I did try with 9.X and experienced the same problem.
I'm working with the 8.X ST flavour but the code looks enough similar in ST 8.X, upstream 8.X and 9rc2.
Looking at the code even the ARM_CM4F post should show the same problem.

The attribute ((used)) solution sounds good to me since I'd say there is no need for -fPIC in FreeRTOS.

I'll see if I can quickly setup a more "build tool" independent example to pack so you could check.
I'm using eclipse managed make that once you pack the directory should work with plain make without eclipse.

I didn't check if I'm missing something for symlinks, but unpacked should be 6Mb. Is it appropriate to drop it here?

thanks

[Richard Barry]

I tried this with Atmel Studio (Visual Studio with arm-none-eabi-gcc)
and Simplicity Studio (Eclipse with arm-none-eabi-gcc).

I don't know what the file size limit is for attachments.

[IvanSB]

I can confirm the problem, at least with 8.2
I'm sorry I haven't had the time to setup a simple test case to pack and send here or come up with a clean set of instructions on how to reproduce the problem but simply turning off lto makes the "undefined reference" error disappear.
This is consistent with the gcc lto FAQ (https://gcc.gnu.org/wiki/LinkTimeOptimizationFAQ) so I'd say that it is more surprising you're not experiencing the problem rather than the other way around.
Looking at the code it is very probable other ports and 9.X should be affected as well.

Even Erich Styger seems to have experienced the same problem.
I've further isolated the problem to vTaskSwitchContext (at least in ARM_CM3 port, put in other ports other functions may be involved).
"undefined reference" for pxCurrentTCB goes away if you switch off -Og.

I'm using gcc version 4.9.3 20150529 (prerelease) (15:4.9.3+svn231177-1) packaged with Debian sid. Maybe newer gcc got smarter and disable lto if -Og is enabled.

I'll try to come up with something so you could reproduce the problem.
Till now I've worked with FreeRTOS in some kind of "vendor" flavour that generally comes with an IDE and build tools "prepackaged". I'll have to disentangle FreeRTOS from the vendor build tool to make it easier to reproduce the problem in an independent way from my environment.

thanks

[IvanSB]

I've seen no change in 9.0.0rc2.

Could we at least see the change proposed by Erich Styger in task.h?

thanks

[Richard Barry]

We are testing with LTO now too.