On 15/04/2020 10.52, Olivier Hainque wrote:
> Hi Rasmus,
>
> Thanks for your proposal.
>
> This is an issue we discussed a bit very recently
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543073.html
>
> and it's nice to see a proposal not requiring
> the replication of all the link spec logic.
>
>
> I had mixed feelings about a change to get gcc -r behave
> differently on VxWorks, but on second thoughts ISTM there
> is sufficient variability in the linkage possibilities on
> that OS to justify some differences.
>
> As a side question to your proposal, have you considered
> the alternative which consists in using gcc -Wl,-r instead
> of gcc -r to build your modules ?
>
> It would be interesting to know if that somehow wouldn't
> work for you.
I'll have to try it, but it sounds like it might work. We still need to
use a custom spec file to specify crtbegin.o/crtend.o as
startfile/endfile, so in that sense it was a bit easier to just also
include the extra logic for sandwiching the objects in that spec file as
well. As you also mention in the thread above, we really want to avoid
duplicating all of LINK_COMMAND_SPEC. Also, using the linker directly is
quite cumbersome, as one would first have to ask gcc via 'gcc
-print-file-name=crtbegin.o' where that file is - it's much neater when
the startfile spec just does its magic.
On a somewhat related note, we're currently carrying this locally in
order to build (link) the vxworks kernel image itself using gcc:
diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
index 0f604f1bcc4..06b4e2e6870 100644
--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -112,7 +112,7 @@ along with GCC; see the file COPYING3. If not see
will treat it as an unrecognized option. */
#undef VXWORKS_LINK_SPEC
#define VXWORKS_LINK_SPEC \
-"%{!mrtp:-r} \
+" \
%{!shared: \
%{mrtp:-q %{h*} \
%{R*} %{!T*: %(link_start) } \
and then module builds must pass -r [or perhaps -Wl,-r depending on how
the above gets solved] explicitly. From the link above, it sounds like
you are already passing -r explicitly and not relying on lack of -mrtp
implying it, so would the above be acceptable for upstream (with proper
changelog and whitespace cleanup of course)?
Rasmus
