issue with behavior change of gcc -r between gcc-8 and gcc-9
Hello, While working on the migration of our production ports to gcc-9, we stumbled on a problem with the behavioral changed introduced by commit 0b7fb27b698da38fd13108ecc914613f85f66f9d Author: Allan Sandfeld Jensen Date: Fri Sep 21 01:38:24 2018 +0600 Fix and document -r option The option has existed and been working for years, make sure it implies the right extra options, and list it in the documentation. The core of the change is summarized by: * gcc.c (LINK_COMMAND_SPEC): Handle -r like -nostdlib. The change is problematic for VxWorks. We initially thought we could get around it, but our ideas unfortunately didn't work out. VxWorks offers various ways to get executable code on a target, one of which consists in downloading a so called "Downloadable Kernel Module", essentially a partially linked blob, then letting the runtime environment finalize the link and prepare the module to run. Preparing the module to run involves running global constructors, for c++ and eh table registration purposes in particular. For this to work, we have sets of crtstuff startfiles and a variety of inclusion policies. The bottom line is that we really rely on the possibility to have startfiles included as part of partial links, which the change above forbids in a pretty irreversible manner (as far as I can see). I'm not entirely clear on the problem the change was trying to solve. IIUC, the essential goal was to remove the need to pass particular options in addition to -r to remove bits from a link closure. Personally, I don't think that need was problematic. As the commit log says, the option has existed and been working for years. -r 's business was to arrange for the linker not to complain because the closure is incomplete, leaving us with complete control of the closure. It doesn't seem to me there was a really strong motivation to suddenly have -r influence the closure the way it now does. Would it be possible to revert to the previous behavior and document it ? Or maybe allow it to be controllable by the target ports ? Or provide something to bring back the flexibility we had if we really believe the default should change ? (I'm not convinced) Thanks in advance for your feedback! With Kind Regards, Olivier
Re: issue with behavior change of gcc -r between gcc-8 and gcc-9
Hello again, > On 01 Apr 2020, at 19:48, Olivier Hainque wrote: > >* gcc.c (LINK_COMMAND_SPEC): Handle -r like -nostdlib. > > Would it be possible to revert to the previous behavior > and document it ? > > Or maybe allow it to be controllable by the target ports ? > > Or provide something to bring back the flexibility we had > if we really believe the default should change ? (I'm not > convinced) I realize we could resort to -Wl,-r instead and I was convinced there are contexts where we don't have the opportunity to control the arguments as freely as we'd like, which would actually restrict our adjustment options. I can triple check on that. Olivier
Re: issue with behavior change of gcc -r between gcc-8 and gcc-9
Olivier Hainque wrote: Hello again, On 01 Apr 2020, at 19:48, Olivier Hainque wrote: * gcc.c (LINK_COMMAND_SPEC): Handle -r like -nostdlib. Would it be possible to revert to the previous behavior and document it ? Or maybe allow it to be controllable by the target ports ? perhaps I’m missing something here, but it is quite possible for a target to override and provide a customised version of LINK_COMMAND_SPEC. Darwin does this: see config/darwin.h So, AFAIU, a port owner has the last call on how such things are handled since the port header is typically included after the generic ones. Or provide something to bring back the flexibility we had if we really believe the default should change ? (I'm not convinced) I realize we could resort to -Wl,-r instead and I was convinced there are contexts where we don't have the opportunity to control the arguments as freely as we'd like, which would actually restrict our adjustment options. cheers Iain
Re: issue with behavior change of gcc -r between gcc-8 and gcc-9
Hello Iain, > On 1 Apr 2020, at 22:42, Iain Sandoe wrote: > > perhaps I’m missing something here, but it is quite possible for a target > to override and provide a customised version of LINK_COMMAND_SPEC. > > Darwin does this: see config/darwin.h > > So, AFAIU, a port owner has the last call on how such things are handled > since the port header is typically included after the generic ones. Sure. I was hoping we could avoid that and maybe have a more specialized control on just that aspect that has changed. There are quite a few things in the default LINK_COMMAND_SPEC and I thought we'd better not start replicating all that logic for just that tiny bit which I wasn't 100% convinced really needed to change. Olivier
Re: issue with behavior change of gcc -r between gcc-8 and gcc-9
On Wednesday, 1 April 2020 19:48:11 CEST Olivier Hainque wrote: > > -r 's business was to arrange for the linker not to > complain because the closure is incomplete, leaving us > with complete control of the closure. > > It doesn't seem to me there was a really strong motivation > to suddenly have -r influence the closure the way it now does. > > Would it be possible to revert to the previous behavior > and document it ? > > Or maybe allow it to be controllable by the target ports ? > > Or provide something to bring back the flexibility we had > if we really believe the default should change ? (I'm not > convinced) -r is used for relinking. The idea behind the change was to make it directly suitable for that. It takes object files and relinks them into a new object file. It gives the caller complete control. It sounds like you are missing some way to add startfiles? A reverse of -nostartfiles? But hopefully you can just use the linker directly? Unless you have LTO enabled object files you dont need the compiler to link. `Allan
Re: issue with behavior change of gcc -r between gcc-8 and gcc-9
Hello Allan, Thanks for following up. > On 02 Apr 2020, at 10:37, Allan Sandfeld Jensen wrote: > -r is used for relinking. The idea behind the change was to make it directly > suitable for that. In my mind, it was just a means to convey "I will relink this somehow later on, don't complain if the closure is incomplete", while you control what goes in the closure or not through means intended for that (-nostdlib, -nostartfiles). > It takes object files and relinks them into a new object > file. It gives the caller complete control. It's true that the caller can resort to -Wl if he doesn't like what -r now does, which is more than before. > It sounds like you are missing some way to add startfiles? A reverse of > -nostartfiles? Sort of, but I'm not sure this would be a better way out than using -Wl. > But hopefully you can just use the linker directly? I don't know yet. > Unless you have LTO > enabled object files you dont need the compiler to link. Part of the issue is all the scripts, makefiles and IDEs driving operations that might implicitly or explicitly rely on a behavior which suddenly changes. Or pieces of documentation here and there. I'm afraid we might have no other choice but to arrange to come back to the previous behavior somehow, at least for VxWorks. I still have at least a few experiments to conduct. Olivier
