From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +gkVHr5V/WYLxz4AWB0awg (envelope-from ) for ; Wed, 02 Oct 2024 10:16:30 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=bOLxp/7T; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6C9F71E353; Wed, 2 Oct 2024 10:16:30 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 253DE1E05C for ; Wed, 2 Oct 2024 10:16:29 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D6191385DDCB for ; Wed, 2 Oct 2024 14:16:28 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id DB5743857349 for ; Wed, 2 Oct 2024 14:16:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DB5743857349 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DB5743857349 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1727878569; cv=none; b=EwOHLsLI5JrVgwReijOvwLhfFYZbvnPzX6ZH4YlkrVtWfEoJLD7jyLDQ1YeA57CgrGyONMiUh7JnqKeUbrNdTm1Zcphj6+gVKO/mzUDdJCfHOz+Lpe8pv9hhICs+ZV3BeeyHAXtgI96leoN/Gv5sSH0g/kQvMFO+5c/AvUrLBeQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1727878569; c=relaxed/simple; bh=XHHsf+rv89yl2tFHoWLTUFliCBmP82j21KLyIrLFr5U=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=DbGspd9g2vKSOwXFSs7hZYt0T59Dfj7eoMeq/tV2mGp5LlD7dFZcGYOqTIPTZWFnjI1qCvZiGD8H8L7Ljgn93JLoWRlsGceXA0587P0LQIhku7CF2vozeSU3rKzpsRombqFwVwd27YcCIHEu0wnauVDULXBNz3aEfThQUgaWv8c= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sw097-0006aD-Ab; Wed, 02 Oct 2024 10:16:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=L2VSZJycNQYaJCslrj9cUSmSJTIGNchSfDSJhgx7OU8=; b=bOLxp/7TXwdd UuQp0fwSzcSRrP2vOkIQj4chobTw3KAppE8Ag9hYT3HlIyTvnVCe/O5cc5dXy6Mr964WVCcTJ3zF4 QMqwYoHY4qwxrHpt1leEfZNh8MHPem/3BuMz4d0wtSW76PKcxG+rY0GaQFRPPx7byMapfRsiuJ+pX VBv3ir/zbyk+VBahI3L8d/TO0v5IvwAegsvNp7lGd92nmiGNlV0TfZ16pbcGBjkxtDiElcn4dS6g4 uvqHC1YeqsaAeFlIVH5x68oAeE0sgAq2jIIR0thzLesfymXI2dAyVxL6LHbr4PR2qTgOsr0UTq58F NK4LBr+YGm6bD8U2Yc9V7Q==; Date: Wed, 02 Oct 2024 17:15:59 +0300 Message-Id: <86ed4y1tgg.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: guinevere@redhat.com, gdb-patches@sourceware.org In-Reply-To: <87setey6vi.fsf@redhat.com> (message from Andrew Burgess on Wed, 02 Oct 2024 14:25:05 +0100) Subject: Re: [PATCH] gdb, configure: Add disable-formats option for configure References: <20240925175340.1850969-1-guinevere@redhat.com> <86msjvars2.fsf@gnu.org> <865xqi9sak.fsf@gnu.org> <8634llaay5.fsf@gnu.org> <87setey6vi.fsf@redhat.com> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org > From: Andrew Burgess > Cc: gdb-patches@sourceware.org > Date: Wed, 02 Oct 2024 14:25:05 +0100 > > Consider the base gdb package as shipped with Fedora Linux. The > `--target' is set to match the `--host', but in addition we pass > `--enable-targets=' to cover a select few architectures running Linux. > There's no Windows, Solaris, FreeBSD, AIX, or any other OS support built > in which means the GDB will not be able to remote debug any of these > targets in a meaningful way[1]. Fedora just doesn't want to commit to > supporting debug for these targets, and this includes both OS and > architecture choices. And that's OK. There are other packages which > offer builds of GDB for specific other target, for example, there's a > package which offers bare-metal AVR support, which is not something the > base gdb package supports. > > However, right now, despite only configuring to support Linux based > targets, Fedora GDB still end up building in support for many different > file formats that we just don't care about, and we'd really like a > configure option that allows distributions to compile out the file > formats that they don't want to support, just as, right now, Fedora > chooses not to support debug on many different OSes. > > I hope this helps a little. It does, thanks. What is still missing is the division of labor between GDB and gdbserver in the remote-debugging scenario. What I thought was that gdbserver only needs to know some part of the target's support, like starting and stopping the program, inserting breakpoints, etc. Whereas GDB needs to be able to read the debug info, access and show the source and machine code, etc. Is that true? If so, then building GDB with support for reading debug info in various formats will allow the user to connect to a gdbserver that supports a specific target, even though GDB itself wasn't built with support for that target (since GDB can connect and talk to a gdbserver from a different build of GDB). Am I wrong about this? If I'm right, then there are two separate aspects to "target": on the one side, the ability to start/stop executables, insert breakpoints and watchpoints, etc., and OTOH the ability to read and process debug info used by that target, implement frame unwinders, etc. Are we currently conflating these into a single notion of "target", and if so, will the proposed changes include or exclude both parts of each "target"?