Message ID | 2254C28C-A28A-4720-A573-CFC2BA60C5A1@arm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 44440 invoked by alias); 19 Feb 2018 14:32:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 44427 invoked by uid 89); 19 Feb 2018 14:32:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com Received: from mail-he1eur01on0069.outbound.protection.outlook.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (104.47.0.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Feb 2018 14:32:10 +0000 Received: from AM3PR08MB0101.eurprd08.prod.outlook.com (10.160.211.19) by AM3PR08MB0724.eurprd08.prod.outlook.com (10.163.189.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 14:32:07 +0000 Received: from AM3PR08MB0101.eurprd08.prod.outlook.com ([fe80::fc60:4b4d:7de8:f8b7]) by AM3PR08MB0101.eurprd08.prod.outlook.com ([fe80::fc60:4b4d:7de8:f8b7%16]) with mapi id 15.20.0506.016; Mon, 19 Feb 2018 14:32:07 +0000 From: Alan Hayward <Alan.Hayward@arm.com> To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> CC: nd <nd@arm.com> Subject: [PATCH] Fix make 3.81 build errors Date: Mon, 19 Feb 2018 14:32:07 +0000 Message-ID: <2254C28C-A28A-4720-A573-CFC2BA60C5A1@arm.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR08MB0724; 7:ZzA7QFbgWG2EFTdPpUgKVAlC+lZ3w7JJCb2oyG9wCEDh8ydGmxWlMBeRv5G/dng7g6AXKkDksVws5GOy6e5HnENaavKAoS3uQHKiJJJHg/Sto+mdIlPh39dnyK7OASzsIbP4NChf2RlUDN/AQUsH8krfTXaF/kIZsQOSn5Mo4ZGrps2fDe8FTrCn/cTODZ1uuTGj8rTvz3nnXe6xsF5b5HI+mmA9J3NLCcg3Pzim/KKWnN7mz1JCNd5b2Y9UQRLT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 982c3cb4-1edf-4c7d-2b4d-08d577a58dca x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:AM3PR08MB0724; x-ms-traffictypediagnostic: AM3PR08MB0724: nodisclaimer: True x-microsoft-antispam-prvs: <AM3PR08MB0724CDB5580FD1BD7903698597C80@AM3PR08MB0724.eurprd08.prod.outlook.com> x-exchange-antispam-report-test: UriScan:(180628864354917); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231101)(944501161)(3002001)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:AM3PR08MB0724; BCL:0; PCL:0; RULEID:; SRVR:AM3PR08MB0724; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(39380400002)(366004)(396003)(376002)(199004)(377424004)(189003)(6436002)(97736004)(26005)(83716003)(1857600001)(59450400001)(33656002)(6486002)(186003)(316002)(7736002)(305945005)(105586002)(53936002)(5640700003)(5250100002)(86362001)(6506007)(5660300001)(102836004)(6916009)(2501003)(6512007)(478600001)(82746002)(72206003)(2351001)(3280700002)(6116002)(3846002)(81166006)(81156014)(8676002)(2906002)(14454004)(2900100001)(66066001)(3660700001)(106356001)(36756003)(99286004)(4326008)(68736007)(8936002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR08MB0724; H:AM3PR08MB0101.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: o1UWASW8aAP4rbni4LPT6MZj9Si1HGVxpHG+0nKKNS5VrakfkgPO4tp7cgKETfwavGrZBMk3/Gudf+Fg/cEYeQ/BI/aIKeYf2OjhtSRBr2DswwquHYyQP8QWrQamKwoW/5PGm1JIZBtzvm5YFC5leKsxg97XpDfTpY9id0nQODs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <6F2224DF8284D845AB583AEC3813ECA0@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 982c3cb4-1edf-4c7d-2b4d-08d577a58dca X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 14:32:07.3376 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR08MB0724 X-IsSubscribed: yes |
Commit Message
Alan Hayward
Feb. 19, 2018, 2:32 p.m. UTC
Make rules in make 3.81 are parsed slightly different than newer versions of make. Patch b5884fa7101cc528f07fd57c3de445a3680964a6 caused build errors on the older 3.81: make[4]: *** No rule to make target `../../../binutils-gdb/gdb/gdbserver/common/btrace-common.c'. Stop. This is because make 3.81 was using the wrong rule to build btrace-common.c, causing it to look in the wrong source directory. This fix simply re-orders the make rules in gdbserver. However, for reasons I am unsure of, this requires moving the corresponding ipa rule. I've tried many many different combinations, and this is the only one that works. Therefore, not pushing as obvious and asking for review first. Tested on x86 and Ubuntu-AArch32-native-extended-gdbserver-m32 builds using both make 4.1 and make 3.81 gdbserver/ 2018-02-19 Alan Hayward <alan.hayward@arm.com> * Makefile.in: Switch order of make rules. --- gdb/gdbserver/Makefile.in | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
Comments
On Feb 19 2018, Alan Hayward <Alan.Hayward@arm.com> wrote: > Make rules in make 3.81 are parsed slightly different than newer > versions of make. Probably this change: * WARNING: Backward-incompatibility! The pattern-specific variables and pattern rules are now applied in the shortest stem first order instead of the definition order (variables and rules with the same stem length are still applied in the definition order). This produces the usually-desired behavior where more specific patterns are preferred. To detect this feature search for 'shortest-stem' in the .FEATURES special variable. Andreas.
> On 19 Feb 2018, at 16:11, Andreas Schwab <schwab@suse.de> wrote: > > On Feb 19 2018, Alan Hayward <Alan.Hayward@arm.com> wrote: > >> Make rules in make 3.81 are parsed slightly different than newer >> versions of make. > > Probably this change: > > * WARNING: Backward-incompatibility! > The pattern-specific variables and pattern rules are now applied in the > shortest stem first order instead of the definition order (variables > and rules with the same stem length are still applied in the definition > order). This produces the usually-desired behavior where more specific > patterns are preferred. To detect this feature search for 'shortest-stem' > in the .FEATURES special variable. > Make sense. But I’m still confused as to exactly why the IPA rules are getting hit. Thanks for the explanation. > On 19 Feb 2018, at 16:16, Simon Marchi <simark@simark.ca> wrote: > > Hi Alan, > > I hit this problem with GNU Make 3.81 before, there's a comment in the gdbserver Makefile: > > # Note: Between two matching pattern rules, GNU Make 3.81 chooses the first one. > # Therefore, this one needs to be before "%.o: %.c" for it to be considered for > # files such as linux-amd64-ipa.o generated from linux-amd64-ipa.c. > # > # Later versions of GNU Make choose the rule with the shortest stem, so it would > # work in any order. > > So to please Make 3.81, you need to order rules from the more specific (shorter stem) > to the more general (longer stem) if you want it to pick up the more specific rule. > That means putting "common/%.o: ../common/%.c" before "%.o: %.c". > > I think there's a way to do it while keeping related rules a bit more together. What > about the patch below? I moved a bit more than necessary (e.g. the arch/ rule) to put > all rules for things that go into the gdbserver binary together and have a similar order > for both gdbserver and the IPA. > Thanks for the patch. I’m happy with this. It’s makes the makefile tidier than with my fix. I’ve tested it on my builds and it works fine for me (make 3.81, make 4) x (x86, aarch32). I would have made my patch look a little neater, but I really didn’t want to touch more than I had to. Alan.
On 2018-02-19 11:39, Alan Hayward wrote: > Thanks for the patch. > I’m happy with this. It’s makes the makefile tidier than with my fix. > I’ve tested it on my builds and it works fine for me (make 3.81, make > 4) x (x86, aarch32). > I would have made my patch look a little neater, but I really didn’t > want to touch more than I had to. > > Alan. Thanks for testing. Can you take care of pushing it? Simon
On 19/02/18 16:39, Alan Hayward wrote: >> On 19 Feb 2018, at 16:16, Simon Marchi <simark@simark.ca> wrote: > Thanks for the patch. > I’m happy with this. It’s makes the makefile tidier than with my fix. > I’ve tested it on my builds and it works fine for me (make 3.81, make 4) x (x86, aarch32). > I would have made my patch look a little neater, but I really didn’t want to touch more than I had to. can you please commit one of the fixes or revert the breaking change.. our toolchain builds are broken because of this.
> On 19 Feb 2018, at 16:44, Simon Marchi <simark@simark.ca> wrote: > > On 2018-02-19 11:39, Alan Hayward wrote: >> Thanks for the patch. >> I’m happy with this. It’s makes the makefile tidier than with my fix. >> I’ve tested it on my builds and it works fine for me (make 3.81, make >> 4) x (x86, aarch32). >> I would have made my patch look a little neater, but I really didn’t >> want to touch more than I had to. >> Alan. > > Thanks for testing. Can you take care of pushing it? > > Simon Pushed as requested. Thanks, Alan.
diff --git a/gdb/gdbserver/Makefile.in b/gdb/gdbserver/Makefile.in index fcb6e1e817f521385de3986861c430c31a1b7eec..e19885c7fef7c82bd2808cfcaa990dbfc5d40c18 100644 --- a/gdb/gdbserver/Makefile.in +++ b/gdb/gdbserver/Makefile.in @@ -541,6 +541,14 @@ arch/%.o: ../arch/%.c $(COMPILE) $< $(POSTCOMPILE) +common/%.o: ../common/%.c + $(COMPILE) $< + $(POSTCOMPILE) + +common/%-ipa.o: ../common/%.c + $(IPAGENT_COMPILE) $< + $(POSTCOMPILE) + # Rules for objects that go in the in-process agent. %-ipa.o: %-generated.c @@ -562,10 +570,6 @@ arch/%.o: ../arch/%.c $(IPAGENT_COMPILE) $< $(POSTCOMPILE) -common/%-ipa.o: ../common/%.c - $(IPAGENT_COMPILE) $< - $(POSTCOMPILE) - arch/%-ipa.o: ../arch/%.c $(IPAGENT_COMPILE) $< $(POSTCOMPILE) @@ -580,10 +584,6 @@ arch/%-ipa.o: ../arch/%.c $(COMPILE) $< $(POSTCOMPILE) -common/%.o: ../common/%.c - $(COMPILE) $< - $(POSTCOMPILE) - %.o: ../nat/%.c $(COMPILE) $< $(POSTCOMPILE)