From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80490 invoked by alias); 3 Jun 2019 16:30:28 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 80469 invoked by uid 89); 3 Jun 2019 16:30:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: gateway31.websitewelcome.com Received: from gateway31.websitewelcome.com (HELO gateway31.websitewelcome.com) (192.185.144.91) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Jun 2019 16:30:26 +0000 Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway31.websitewelcome.com (Postfix) with ESMTP id AF08B1EAD for ; Mon, 3 Jun 2019 11:30:24 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id XpqqhPKRq90onXpqqhRPH6; Mon, 03 Jun 2019 11:30:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=i0HUkTN3+eqDyDd0kDAUybgwf739V9RMujMQy7qSpSs=; b=NfKitv++sxln8E628/pGhNi43H lRtS8zz/RNI37KBmCGT8ELvPtR+SPKmsxvyShrrgVidPQIrg0Km0cVJS88waZuCygCNIey7unKmY5 KwgOfQP7ZmLimpAEEf11JM26t; Received: from 174-29-48-168.hlrn.qwest.net ([174.29.48.168]:58750 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hXpqq-003uFP-Df; Mon, 03 Jun 2019 11:30:24 -0500 From: Tom Tromey To: Simon Marchi Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFC 0/2] Let's discuss moving gdbserver to top-level References: <20190530213046.20542-1-tom@tromey.com> <5e3c0a94-773c-4ea7-0d25-87c5273c52f5@simark.ca> Date: Mon, 03 Jun 2019 16:30:00 -0000 In-Reply-To: <5e3c0a94-773c-4ea7-0d25-87c5273c52f5@simark.ca> (Simon Marchi's message of "Mon, 3 Jun 2019 10:27:26 -0400") Message-ID: <87ftoqocm8.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-06/txt/msg00031.txt.bz2 >>>>> "Simon" == Simon Marchi writes: Simon> Just some questions about how things will work after such a move (at least, how it Simon> is in your branch). Simon> I suppose that there will be a top-level --enable-gdbserver/--disable-gdbserver. Simon> switch like there is for other components? Yes. This is provided automatically by the top-level configure. Simon> If so, what happens if you do something like Simon> ./configure --host=x86 --target=arm --enable-gdb --enable-gdbserver Simon> ? Currently, if the host and target architectures are different, gdbserver won't be built Simon> (this check is done in gdb/configure.ac:2181). I forgot to implement any logic to disable gdbserver in the cross scenario. I will be sure to do that before submitting the series. Simon> Is gdbserver silently skipped, or does it error out saying that you can't enable gdbserver Simon> if host != target? I'm not sure what it should do in this situation. Maybe erroring out is best, since it is a user error to do this. The basic idea here, though, is to turn gdbserver from something special with its own instructions into something that can be treated like the other top-level directories. Simon> Do you know about anything else in the binutils-gdb tree that is Simon> built to run on the target? Nope. Tom