From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50858 invoked by alias); 22 May 2019 00:04:25 -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 50850 invoked by uid 89); 22 May 2019 00:04:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 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*c:ISO-8859-1, H*UA:en-US, HTo:U*macro X-HELO: mail-ot1-f68.google.com Received: from mail-ot1-f68.google.com (HELO mail-ot1-f68.google.com) (209.85.210.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 May 2019 00:04:23 +0000 Received: by mail-ot1-f68.google.com with SMTP id 66so480455otq.0 for ; Tue, 21 May 2019 17:04:23 -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=xbm3QfEnKDoK7c8TOvTW5kPrmdD8aLDRD2hirXpXZZI=; b=QAydz+bMywKVC4wmSXH1O6w436jILSyKUkSJyPYjlURvsjw3vx7ienMSJhCtzPgEYo 6iAvPOznb7fDjqXwoQfmStjtZwLoPnshwVXqHPBnzTT/NPNIceKhU7bQFd5lNvCeUNf8 j2x38yM6XO+93oY7vkTrhKHjnFLT9ttJipi5d5xqag9Vw85FC0hFjm6ZYi9++7Uecmsd 8YPbtxJG7/6wEAEu/+8WV8J7aK42O/7MPp0g3fZJNuXQisKTXpnhquM8obuy+KsQXMkc allOKM8MmFrptvRkdHGR4KDN9h6znPzRZlWFGmzWLzLsDbVYfZ94kWO0OPSEf117LfmC fIaA== Return-Path: Received: from [192.168.2.42] (adsl-70-133-145-189.dsl.ablntx.sbcglobal.net. [70.133.145.189]) by smtp.gmail.com with ESMTPSA id w130sm3358585oib.44.2019.05.21.17.04.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 May 2019 17:04:20 -0700 (PDT) Message-ID: <5CE49202.6010705@gmail.com> Date: Wed, 22 May 2019 00:04: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 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: <5CDCA82D.8090204@gmail.com> <5CDDF492.5010308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg01449.txt.bz2 Maciej Rozycki wrote: > On Thu, 16 May 2019, Jacob Bachmeyer wrote: > > >>> I suspect the origins may be different, however as valuable as your >>> observation is functional problems have precedence over issues with code >>> structuring, so we need to fix the problem at hand first. I'm sure >>> DejaGNU maintainers will be happy to review your implementation of code >>> restructuring afterwards. >>> >> My concern is that your patch may only solve a small part of the problem >> -- enough to make your specific case work, yes, but then someone else >> will hit other parts of the problem later and we spiral towards "tissue >> of hacks" unmaintainability. >> > > I think however that fixing problems in small steps as they are > discovered is also a reasonable approach and a way to move forward: > perfect is the enemy of good. > Fair enough; observe the small patches I have recently submitted to DejaGnu. > So I don't think the prospect of making a comprehensive solution should > prevent a simple fix for the problem at hand that has been already > developed from being applied. > I recognize a difference between "simple but complete" (an ideal sometimes achieved in practice) and "simple because incomplete" (which does not actually fix the problem). My concerns are that your patch may be the latter. > IOW I don't discourage you from developing a comprehensive solution, > however applying my proposal right away will help at least some people and > will not block you in any way. > Correct, although, considering how long my FSF paperwork took, I might be able to finish a comprehensive patch before your paperwork is completed. :-) >> The biggest hint to me that your patch is incomplete is that it only >> adds -largs/-margs to wrap LDFLAGS. I suspect that there are other >> -?args options that should be used also with other flag sets, but those >> do not appear in this patch. Do we know what the GNU Ada frontend >> actually expects? >> > > At first glance it looks to me we should be safe overall as compiler > flags are supposed to be passed through by `gnatmake' (barring switch > processing bugs, as observed with 1/3), and IIUC assembler flags are > considered compiler flags for the purpose of this consideration as > `gnatmake' does not make assembly a separate build stage. So while we > could wrap compiler flags into `-cargs'/`-margs', it would only serve to > avoid possible `gnatmake' switch processing bugs. > I am not sure if those are actually bugs in `gnatmake' or the result of an incomplete specification for `gnatmake' -- I suspect that --sysroot= may have been added to the rest of GCC after `gnatmake' was written and whoever added it did not update the Ada frontend. > There's also `-bargs' for binder switches, but I can't see any use for it > here. > > Finally boards are offered the choice of `adaflags', `cflags', > `cxxflags', etc. for the individual languages, where the correct syntax > can be used if anything unusual is needed beyond what I have noted above. > Which also raises the issue of "cflags_for_target" (used regardless of language and currently always taken from the "unix" board configuration) and how that is supposed to make sense and whether it should be similarly split into language-specific values or simply removed. I have already submitted a patch to draw that value from the actual host board configuration. > I'll defer any further consideration to the Ada maintainers cc-ed; I do > hope I haven't missed anything here, but then Ada is far from being my > primary area of experience. > Likewise, hopefully some of the Ada maintainers will be able to shed light on this issue. And I hope Ben (the DejaGnu maintainer) is okay -- I would have expected him to comment by now. >>> The ordering rules are system-specific I'm afraid and we have to be >>> careful not to break working systems out there. People may be forced to a >>> DejaGNU upgrate, due to a newer version of a program being tested having >>> such a requirement, and can legitimately expect their system to continue >>> working. >>> >> We can start by simply preserving the existing ordering until we know >> something should change, but the main goal of my previous message was to >> collect the requirements for a specification for default_target_compile >> so I can write regression tests (some of which will fail due to known >> bugs like broken Ada support in our current implementation) before >> embarking on extensive changes to that procedure. Improving >> "target.test" was already on my local TODO list. >> > > You are welcome to go ahead with your effort as far as I am concerned. > I am working on it. :-) -- Jacob