From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42587 invoked by alias); 16 May 2019 00:00:51 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 42516 invoked by uid 89); 16 May 2019 00:00:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=H*u:en-US, H*UA:en-US, uncertain, expressed X-HELO: mail-ot1-f65.google.com Received: from mail-ot1-f65.google.com (HELO mail-ot1-f65.google.com) (209.85.210.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 May 2019 00:00:49 +0000 Received: by mail-ot1-f65.google.com with SMTP id t24so1713163otl.12 for ; Wed, 15 May 2019 17:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=FVU0Y/jWBZDVWW8OuQy3aOzC3un8HGkWdNrq9nSfNNM=; b=W8DcZO5otrEbgHug31Fhd/DE2zftKk73n8H+MJSeIEZzJQrhgs3Kd2q+6Nm1UibjIy j0uWTee1oKHb5rzIR7cjooAWaI9eN0AhBpeZTV3bfp+bwpBmoaNrx+jSPItrMLvVsSwk DNRa/5cGHhiSElOyBgLr4zt1M32J8+EjtyNr/S7nnb3t6x7UaeyZ0TeYdWnhgVGxD4JJ zirnaeg2z5d48XGOB1c+gxHxJpTlkjJ7Kb5P+FlDT6rHZvYWKOEpil0JOYk8Gk8HHQYH Fgzn+IU4FdluzY/SFRAro2gqy7a3cWf72Ou0ULuL5iuomIRiL7f/UXavO75PikwyqvsC yM6g== Return-Path: Received: from [192.168.2.42] (adsl-70-133-144-166.dsl.ablntx.sbcglobal.net. [70.133.144.166]) by smtp.gmail.com with ESMTPSA id m124sm1216964oia.3.2019.05.15.17.00.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 May 2019 17:00:46 -0700 (PDT) Message-ID: <5CDCA82D.8090204@gmail.com> Date: Thu, 16 May 2019 00:00:00 -0000 From: Jacob Bachmeyer Reply-To: jcb62281@gmail.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: "gcc-patches@gcc.gnu.org" , "dejagnu@gnu.org" , Pierre-Marie de Rodat , Arnaud Charlet , Eric Botcazou Subject: Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00898.txt.bz2 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