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

[Olivier Hainque <hainque@adacore.com>]

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