From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15437 invoked by alias); 25 Jan 2019 20:13:00 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 15422 invoked by uid 89); 25 Jan 2019 20:13:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=doubt, H*i:sk:8c0e12a, H*f:sk:8c0e12a X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Jan 2019 20:12:59 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 03F0CA171C; Fri, 25 Jan 2019 20:12:58 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 60411600D6; Fri, 25 Jan 2019 20:12:57 +0000 (UTC) Subject: Re: Supported Systems page on the Wiki To: John Baldwin References: <5c9713be-ef32-c17e-bba4-f07fab0af428@FreeBSD.org> <58253495-ea94-9881-29a6-80ee45a37115@redhat.com> <8c0e12ac-4aac-bb72-95d5-8f3655c823e2@FreeBSD.org> Cc: "gdb@sourceware.org" From: Pedro Alves Message-ID: Date: Fri, 25 Jan 2019 20:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8c0e12ac-4aac-bb72-95d5-8f3655c823e2@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-01/txt/msg00033.txt.bz2 On 01/25/2019 07:06 PM, John Baldwin wrote: > On 1/25/19 9:59 AM, Pedro Alves wrote: >> On 01/25/2019 05:48 PM, John Baldwin wrote: >>> I was looking at the supported systems page on the wiki recently (I made >>> some minor updates yesterday) and noticed the second table (Supported Targets) >>> is currently missing. There also isn't a table for which configurations >>> support native targets. Thinking about this a bit more, I feel that if we >>> do fill in the missing second table the page would probably end up a bit >>> long. If we further added a table listing native targets, that would make >>> the page even longer. >> >> I'd think a table listing native targets would be about the same as the >> hosts table, though. > > That was a question I forgot to ask is does a Native column even make sense > or will it effectively always be true that if GDB is supposed as a host > and a target it probably has a native target as well? > In the general case, that could well be false. But in practice, I'm not sure the general case matters. I'd assume that any POSIX-like OS supported by gnulib will be able to build gdb, even if we don't have a native port for it, or target support. That GDB would be usable as a cross/remote debugger. Is it useful to try to find such systems and list them in the table with only a "host" column checked? Probably not. Cases that come to mind are native ports for which support was obsoleted and removed, _and_ don't barf on the "Configuration $host is obsolete." check in gdb/configure.host. Speaking of which, I guess pedantically that error is incorrect, since you could pedantically still want to build a cross debugger hosted on those systems... Other cases could be some new new architecture running Linux, *BSD, etc. I'd assume that it is usually possible to build and use GDB as a cross debugger on such a system, even if we don't have a native port yet, because new native ports for new architectures don't usually need fixes to common code. Assuming GDB already supports the operating system, that is, of course. We could look at the set of gdbserver's supported systems and compare that to gdb's native systems. There are a number of ports for which there are no corresponding gdb native support files. CRIS Linux, for example? But those would already get a line in the table, with checks on the "target" and "gdbserver" columns. Is is useful to try to determine whether gdb can be built on such a system, even if it doesn't support native debugging? Doubt it. Maybe just a general "GDB builds on most POSIX-like hosts." remark is sufficient. Then we would only have the "native" column, no "host" column. Of course, we can always change the table if we find a use for adding info. Thanks, Pedro Alves