issue with behavior change of gcc -r between gcc-8 and gcc-9

issue with behavior change of gcc -r between gcc-8 and gcc-9

[Olivier Hainque]

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 <allan.jensen@qt.io>
  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

[Olivier Hainque]

Hello again,

> On 01 Apr 2020, at 19:48, Olivier Hainque <hainque@adacore.com> 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

[Iain Sandoe]

Olivier Hainque <hainque@adacore.com> wrote:

> Hello again,
>
>> On 01 Apr 2020, at 19:48, Olivier Hainque <hainque@adacore.com> 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

[Olivier Hainque]

Hello Iain,

> On 1 Apr 2020, at 22:42, Iain Sandoe <iain@sandoe.co.uk> 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

[Allan Sandfeld Jensen]

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

[Olivier Hainque]

Hello Allan,

Thanks for following up.

> On 02 Apr 2020, at 10:37, Allan Sandfeld Jensen <allan.jensen@qt.io> 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