From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yI/fNuAtBWd+CwYAWB0awg (envelope-from ) for ; Tue, 08 Oct 2024 09:04:32 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=FgxaONnj; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DA9BE1E355; Tue, 8 Oct 2024 09:04:32 -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 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 116931E353 for ; Tue, 8 Oct 2024 09:04:32 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8BA573850200 for ; Tue, 8 Oct 2024 13:04:31 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 573DE3858D29 for ; Tue, 8 Oct 2024 13:04:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 573DE3858D29 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 573DE3858D29 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728392649; cv=none; b=r2pDkxBTsfiMoNNSmysZ8oZRoVZqiftEFzHuAuUrPj47PNJTZ0fdTDrOMVwPjyzuZVPRuqFpHcSfVBuHT18Ui6Wt3cFmUVI7wt+LLUDuXY9iEq54WAbGzhZid5DJDbrB8GNZv6pMbYXd2WrCLNJfURBKNCHnOgh2TrJF6yMUZwQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728392649; c=relaxed/simple; bh=eJz6ycnxXMl7Wd9XV9iLLNaSq/TGzcRWIyFxcFw8exc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=EmGgEdAJJ+sMeF6kUN+tG1f2EC9xp10v3dW3G/O3/d9sjTxfDqsZPF98CT2XGiHbi62uaZfypz9nq86ykFmd9VkQCvFOLdT0Ya1VPkjtLMTFo5/khqZ2SNRS/ND7O76aKjshHCpO2iC9epBNzms+tdEsc8xk14WzGcMRgpDgmHs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1728392644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QYZ7nZUqRwajF3KijL+V5PGbHtDkF9W1Eb9uJkdgsCc=; b=FgxaONnjmFRXA6YSkH87J26Rs/jjTEEB2JHPtWjASvA68/cNJPhEjHWaReTDkPYJciBl6b fHaNH7rv+dMHWZDFQGgHdrgCIzs9Ng1eE2r+37Bbf+12QIS+zoQx4hDsfoF2PrBQTDb6+n +Kkg9Ti9zQjoO0qO65viwQaQYcIGSfA= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-623-BVcBDNZmP1W3FQ2iLSPbnQ-1; Tue, 08 Oct 2024 09:04:02 -0400 X-MC-Unique: BVcBDNZmP1W3FQ2iLSPbnQ-1 Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-4582790fc3cso110111921cf.0 for ; Tue, 08 Oct 2024 06:04:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728392642; x=1728997442; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QYZ7nZUqRwajF3KijL+V5PGbHtDkF9W1Eb9uJkdgsCc=; b=J0pQ6u7sVaDuFvkjcSz6IVccM/S/yQV8NkiQBflULlTKM+ymAGYmCmvJmAvp+qn0A3 mHdKCaPwHAb0+qLnT79WlO+BiFejE81l7TNr9tQ9Kofd41tew8pXevBrQJAGNo0+K9/h cKgOvKQKB1t3EPrZbor6A2NYaKVrHZWQBZt7lX4HDNgFZGAXRQOeUuHMPBMWdvlCB99K 3hyv/x2GwtwezE/aQAdfs1hTqR0bF/a6mNmGAOBVDXXsmuYZEU4JqYTgXEHSHb5Fwtsu ykIiYFyoLHIQyQznTz0u8LWgSuEBPgbTRBEczX+hBab/QQu56f9lfIV1KDVoYacSA0Kg 3QNQ== X-Forwarded-Encrypted: i=1; AJvYcCV1EeONCRuOu59sYopria+8BBaKetF62YnFTC8LGeh14mFvyQujV5nxgvQxoxnHx9z2RNbv7AUGq0ghtg==@sourceware.org X-Gm-Message-State: AOJu0YzAsJpxAypA4k+xTUUQNsqAryW2XkIuJRdh7o6+kRnHZgcu1kAs LMwll+Go248jyQzvFq0vcFGT8m0R5rDNDGikeM0XvTyX8uHeo+pOy1pF/Bo7OkKY0tRKSHY11h8 zpk9zRuRKlmWGepqF15Vk4a8g/U7uC/07OyBP7XAav/zcAzQeMoOI+9ze5ZY= X-Received: by 2002:ac8:5f84:0:b0:458:2e67:feb6 with SMTP id d75a77b69052e-45d9ba4136dmr232922901cf.11.1728392642112; Tue, 08 Oct 2024 06:04:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFJlrCr7G746jH7uTF2KhQG1MGki/fmohz2kSnIqJKbw4QyslfrfvT8/MzxhFuo12ty6aHU5A== X-Received: by 2002:ac8:5f84:0:b0:458:2e67:feb6 with SMTP id d75a77b69052e-45d9ba4136dmr232922571cf.11.1728392641685; Tue, 08 Oct 2024 06:04:01 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:92c5::1000? ([2804:14d:8084:92c5::1000]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-45da74e9fcdsm36072961cf.27.2024.10.08.06.04.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Oct 2024 06:04:01 -0700 (PDT) Message-ID: <49074401-6680-4ed1-9263-c098053f8ed9@redhat.com> Date: Tue, 8 Oct 2024 10:03:58 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb, configure: Add disable-formats option for configure To: Eli Zaretskii Cc: aburgess@redhat.com, gdb-patches@sourceware.org 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> <861q0qu8d7.fsf@gnu.org> From: Guinevere Larsen In-Reply-To: <861q0qu8d7.fsf@gnu.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 On 10/8/24 8:44 AM, Eli Zaretskii wrote: >> 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. Then I guess the response you wanted is the paragraph you omitted in this response:     Once they know what target they are running, it will most likely be Linux, Windows or MacOS, which are called out by name in this description. If it is something different, the user is likely savvy enough to look up online what their operating system supports, as there are no users of these platforms who do so because it's the default in the mainstream machine they bought. If you know that your platform is FOO, you can either easily find it in the list, or it is a specialized system that you chose to use, and are likely to know better than me where to find that information. > > 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. Which is all the more reason for GDB to not be the owner of this type of documentation. I couldn't find any information about how core files were handled in Windows, but as soon as you - someone who clearly knows the system - brought up that maybe elf should be used with cygwin, a quick search for the specification found a footnote confirming this. We should not be expected to keep on top of all the specifications of all targets we own so we can suggest to possible users that maybe they want this if they use some specific configuration. Ultimately, this is a feature for advanced users who have deep domain knowledge on the systems they expect to handle, and similar to how, even with the update on the --target and --enable-targets documentation, I wouldn't expect every single target triplet supported by GDB to be listed in the documentation, I don't think we should list what formats are recommended for each target. I can change the first paragraph of the description to read as follows:   Configure GDB to only be be able to read selected file formats. The   special value "all" causes all file formats to be compiled in, and is the   the default behavior of the option. If you are unsure of which options   you will need for your debugging sessions, we recommend that you   not make use of this function. The possible options are: > >> 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. > -- Cheers, Guinevere Larsen She/Her/Hers