From: Jacob Bachmeyer <jcb62281@gmail.com>
To: "Maciej W. Rozycki" <macro@wdc.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
"dejagnu@gnu.org" <dejagnu@gnu.org>,
Pierre-Marie de Rodat <derodat@adacore.com>,
Arnaud Charlet <charlet@adacore.com>,
Eric Botcazou <ebotcazou@libertysurf.fr>
Subject: Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada
Date: Thu, 16 May 2019 00:00:00 -0000 [thread overview]
Message-ID: <5CDCA82D.8090204@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1905142145350.18422@tpp.hgst.com>
Maciej W. Rozycki wrote:
> Unrecognized `gnatmake' switches are not implicitly passed on to the
> linker, so just pasting board `ldflags' and any other linker flags
> verbatim into `add_flags' to use for the invocation line of `gnatmake'
> will make them ignored at best.
>
> [...]
>
> For `gnatmake' to pass switches on to the linker the `-largs' switch has
> to be used, which affects all the switches that follow until a switch is
> seen that changes the selection, like `-margs', which resets to the
> initial state of the switch interpretation machine.
>
> Wrap linker flags into `-largs'/`-margs' for Ada then, carefully
> preserving the place these flags are placed within `add_flags', as
> surely someone will have depended on that, [...]
Fortunately, `add_flags' is a procedure local variable in
default_target_compile, so it is not visible outside of that procedure.
This patch really exposes a significant deficiency in our current
implementation of default_target_compile: the order of various flags
can be significant, but we only have that order implicitly expressed in
the code, which goes all the way back to (of course) the "Initial
revision" that is probably from a time before Tcl had the features that
will allow significant cleanup in here.
Rather than introducing more variables, I propose changing add_flags to
an array and collecting each category of flags into its own element,
then emitting those elements in a fixed order to build the `opts' list.
This would also allow us to easily support other cases, for example,
prefixing "special" linker flags with "-Wl," or similar handling for
other frontends. I think we only need to support GCC command syntax,
which simplifies the issue a bit, but even GCC frontends are not 100%
consistent, as this issue with gnatmake shows.
What categories do the flags currently accumulated in `add_flags'
cover? I see at least:
- compiler flags (adaflags/cxxflags/dflags/f77flags/f90flags)
- explicit additional flags ("additional_flags=" option)
- explicit ldflags ("ldflags=" option)
- libraries ("libs=" option)
- preprocessor search paths ("incdir=" option)
- linker search paths ("libdir=" option and [board_info $dest libs])
- linker script ("ldscript=" option or [board_info $dest ldscript])
- optimization flags ("optimize=" option)
- target compiler flags from host ([board_info $host cflags_for_target])
- type selection flag ("-c"/"-E"/"-S")
- target compiler flags ([board_info $dest cflags] *regardless* of
the compiler selected)
- target linker flags ([board_info $dest ldflags])
- special flags for C++ ([g++_link_flags])
- an attempt to locate libstdc++, also regardless of compiler
- debug flags, if the "debug" option is given
- the math library
- "-Wl,-r" if board_info knows a "remote_link" key
- "-Wl,-oformat,[board_info $dest output_format]" if that is defined
- multilib flags, currently *prepended* if defined
- a destination file
Some of these could probably be combined and I may have combined
categories that should be separate in the above list. The GNU toolchain
has always been a kind of "magic box that just works" (until it doesn't
and the manual explains the problem) for me, so I am uncertain what the
ordering rules for combining these categories should be. Anyone know
the traditional rules and, perhaps more importantly, what systems need
which rules?
-- Jacob
next prev parent reply other threads:[~2019-05-16 0:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 21:46 [PATCH 0/3] GNAT test suite fixes for build sysroot Maciej W. Rozycki
2019-05-14 21:47 ` [PATCH 1/3][GCC] gnatmake: Accept the `--sysroot=' GCC driver option Maciej W. Rozycki
2019-05-14 21:48 ` [PATCH 2/3][GCC] GNAT/testsuite: Pass the `ada' option to target compilation Maciej W. Rozycki
2019-05-15 23:12 ` Jacob Bachmeyer
2019-05-16 12:38 ` Maciej W. Rozycki
2019-05-16 22:57 ` Jacob Bachmeyer
2019-05-14 21:49 ` [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada Maciej W. Rozycki
2019-05-16 0:00 ` Jacob Bachmeyer [this message]
2019-05-16 12:58 ` Maciej W. Rozycki
2019-05-16 23:39 ` Jacob Bachmeyer
2019-05-21 21:37 ` Maciej Rozycki
2019-05-22 0:04 ` Jacob Bachmeyer
2019-10-25 17:40 ` [PING^3][PATCH " Maciej W. Rozycki
2019-10-26 1:30 ` Jacob Bachmeyer
2019-06-19 12:16 ` [PING][PATCH 0/3] GNAT test suite fixes for build sysroot Maciej Rozycki
2019-06-19 12:49 ` Arnaud Charlet
2019-06-20 14:51 ` Maciej Rozycki
2019-06-20 15:14 ` Arnaud Charlet
2019-06-20 15:32 ` Maciej Rozycki
2019-09-13 17:56 ` [PING^2][PATCH " Maciej W. Rozycki
2019-09-16 9:12 ` Arnaud Charlet
2019-09-23 23:21 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5CDCA82D.8090204@gmail.com \
--to=jcb62281@gmail.com \
--cc=charlet@adacore.com \
--cc=dejagnu@gnu.org \
--cc=derodat@adacore.com \
--cc=ebotcazou@libertysurf.fr \
--cc=gcc-patches@gcc.gnu.org \
--cc=macro@wdc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).