[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs
Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada
Wed, 15 May 2019 19:00:45 -0500
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/20090807 MultiZilla/184.108.40.206e SeaMonkey/1.1.17 Mnenhy/0.7.6.0
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
[PATCH 1/3][GCC] gnatmake: Accept the `--sysroot=' GCC driver option, Maciej W. Rozycki, 2019/05/14
[PATCH 2/3][GCC] GNAT/testsuite: Pass the `ada' option to target compilation, Maciej W. Rozycki, 2019/05/14