[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs

From: Jacob Bachmeyer
Subject: Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada
Date: Wed, 15 May 2019 19:00:45 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]