From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id g/qwLkAbBWd9+QUAWB0awg (envelope-from ) for ; Tue, 08 Oct 2024 07:45:04 -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=azVWtrhN; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A5B071E355; Tue, 8 Oct 2024 07:45:04 -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 4B8021E353 for ; Tue, 8 Oct 2024 07:45:03 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 980C33861812 for ; Tue, 8 Oct 2024 11:45:02 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 97FFF385842D for ; Tue, 8 Oct 2024 11:44:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 97FFF385842D 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 97FFF385842D 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=1728387884; cv=none; b=K7gbRSQ2WEjLh2g4CQDeIMlXUPvDm6v3ZUPeSxWhx3WAmEqKftR/UPrqUlBO/5jt4ZEc47oeUYfOhAVWkfT9Kj9JJ/A1yAXiCZ5j5AwIRXlUpFdhABiSjFb7H3g5i1RkXCVcIMitrYzs4oyyLuWVNPFxIh6Nji4FDfHGBsqKhW0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728387884; c=relaxed/simple; bh=2Aazap5OH4Mt1LrPokVc98NC5qqnQ9i9MV/ZErunahs=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=IZXws+BhPjFhsGcgXumERP54wj7YFywgh9cD+H4fq2w2zuQKjZVRjQqGzo3fGJSXa3BEYKoUTSPXSqhsW9Qm1ctSWoZacbZyWCHOtjHwljMGnA30Lf0wx1IlLn8IrD1SRw8CTSE3KpjUeLPN+Nm/LwS0gGiz3bTQRK+DuhJHXxI= 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 1sy8ds-00010k-Fz; Tue, 08 Oct 2024 07:44:40 -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=YzjPutnDgwjTYcF1ADjRSAd2l7fgCd6WHmA5bloyVg4=; b=azVWtrhNKWIS ncy8u7BmCWZXVAaunCiA4uF3IbGJl2q9ixzxrThntB0HO7sR0Nde6wZmlXO9FB87F+FzBZn5g/RXR GJsOxeNC6Nx7SBn7awXKSzDgBy5lpSTac/IMp9PzthJK8TdZ6cVb/VlLu2xhgs1gprT38XnaKY5AY KXIt5cRGmO0nw2+8VPjOYcI6bTfJX6g994COhro4DvIR9tH9wWF8bzIx+8MbYncxIeIfz4zECUu7J ibBFQEj3DGwxNh7o0BVzP273u8KYsgSqB0MHd2ftPvQG6FlBv6n6fR82QpgBG8k3NvkRkhGqfZBpG aCRwyZZncCBRzNvuQpMMgA==; Date: Tue, 08 Oct 2024 14:44:36 +0300 Message-Id: <861q0qu8d7.fsf@gnu.org> From: Eli Zaretskii To: Guinevere Larsen Cc: aburgess@redhat.com, gdb-patches@sourceware.org In-Reply-To: <59157ccb-69cd-4d23-9e39-89bb211583f8@redhat.com> (message from Guinevere Larsen on Mon, 7 Oct 2024 16:58:16 -0300) 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> <86ed4y1tgg.fsf@gnu.org> <87bk00x7u6.fsf@redhat.com> <86ed4wx6yt.fsf@gnu.org> <86a5ffu3ij.fsf@gnu.org> <59157ccb-69cd-4d23-9e39-89bb211583f8@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 > Date: Mon, 7 Oct 2024 16:58:16 -0300 > Cc: aburgess@redhat.com, gdb-patches@sourceware.org > From: Guinevere Larsen > > On 10/7/24 4:17 PM, Eli Zaretskii wrote: > > That's a good starting point, but IMO it stops short of answering the > > practical questions people will ask themselves. For example, how do I > > configure GDB to support a single target that is my native target and > > OS? will specifying the single format from the above list do? > > If a user wants to configure their native target, that is related to the > --target and --enable-target options. Not the file formats. This change > is not related to how a user decides to support any given CPU or > operating system, but rather, which binary files they wish GDB to be > able to understand. If the user knows they want Windows and Linux, but > don't know how to specify that, they should look at documentation for > --target and --enable-targets, which is not touched by this patch or > related to this change whatsoever. I think there's a misunderstanding. I said "to support a single target", meaning _only_ that single target. You seem to be saying that --target is what I want, but that's not what I knew. Right now, when I compile GDB for native Windows debugging, I get all the *read.c files compiled and linked into GDB. I don't specify --target when I build GDB, but I do specify --build, and I thought that --build=FOO is a short for --host=FOO --target=FOO. So I thought that I am already specifying --target, and yet I get all the binary-format readers compiled and linked in. So I was asking what should I do at configure time to have only the *read.c files I need for that single target and only for native debugging. If you are saying that the --enable-binary-format is unrelated to my questions, then I guess I'm even more confused than I thought I was. > > One thing I remember is that many targets produce core files in ELF > > format. If that is true, then omitting ELF should be discouraged for > > that reason. And maybe also other similar practical factoids. > > > I believe that is the case because there are many targets that use ELF > as the objfile format. True, but not what I was saying: I was specifically alluding to targets whose objfile format is _not_ ELF, and yet they produce core files in ELF format. ISTR that Cygwin is one such target? I'm sure others here will be able to find more examples. > And once again, users don't need to interact with this feature. If it is > completely ignored, GDB will continue to work just as it did before this > patch went in. I understand, and that is good, but I'm talking from the POV of someone who _wants_ to use this new feature, in order to make GDB smaller. Thanks.