From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id lnprDno9BGdQJAUAWB0awg (envelope-from ) for ; Mon, 07 Oct 2024 15:58:50 -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=Uc/YBmBy; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1ACC81E355; Mon, 7 Oct 2024 15:58:50 -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 3A2FF1E05C for ; Mon, 7 Oct 2024 15:58:49 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 747853861015 for ; Mon, 7 Oct 2024 19:58:48 +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 BB1F7386103F for ; Mon, 7 Oct 2024 19:58:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BB1F7386103F 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 BB1F7386103F 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=1728331104; cv=none; b=kFGKEV29FFxKHNGaU1zs6GItViayeBgwrCjyjwuhnApU4Kn5VvoeSBDK74YkpjuIIXl97+nRqCodPgZErw031OFewBnUcJNvxANSyDvRnBH8qK02PmYOafHUjGxUfom9qAFFARC9iTXoZfgcH20Df5zSnfNEBbcKsBYXPpl0rjY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728331104; c=relaxed/simple; bh=BjTuZlog/Tak/5jz3dr61IRpf4f+Ha+vlOyoBDMoc3w=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=JgmwsTvewTPxSANJdDXzcZexWPwpUAHsnLn8Yvg9I1Bhuw1XlxswkmxU8nAQPaZFvUPeYqZs9JEH/dp0ckaFuMlLj/0RE6bXxcCqpc92aobRY2i4895s3KBZj/iQO30APZQ04u0l8YDJDM91iMQq7blNK6/BDFcTW0ztmuhk644= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1728331102; 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=8seN4eSV9g2JKSZlrwc+Gtv6zoQhllaSvsVNSUETw+8=; b=Uc/YBmByq9go13EQ1KDrAMRsbxOA2y3Ic9OwYIXCJtA4envpIp3ez1qUK6qV5LpC4kyNxw gWLYsR8m7LAeZF835Om8HG1OSc4AhcPHtxLZjlFOKSfH7c1QTgqFrmN8DlE5mTDbqyenys kaZ7nrIB1eEKCOQuNy0lEdFZE3zajW0= Received: from mail-io1-f70.google.com (mail-io1-f70.google.com [209.85.166.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-219-xqMBhUmpO3y81IKTJyRtuA-1; Mon, 07 Oct 2024 15:58:21 -0400 X-MC-Unique: xqMBhUmpO3y81IKTJyRtuA-1 Received: by mail-io1-f70.google.com with SMTP id ca18e2360f4ac-82cf261659bso768134039f.2 for ; Mon, 07 Oct 2024 12:58:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728331101; x=1728935901; 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=8seN4eSV9g2JKSZlrwc+Gtv6zoQhllaSvsVNSUETw+8=; b=OAHYnPREvdCaoCwZm2hweHW6XY8agSjDx+DFu8CR6RSSHzEv4L3eQ+0jEUo4VG787x 4U6trqXuHejN/vrQcxgDGwlCNGW0XjbMeQqwXy2guWI8Xpa2YDbBpz4emQpNBwzvHXde ZovgqftjQ71EDeSrv+NHxwCMuUXEn3ZtrRJ6vIAUAyx7ohmuZAWN6aT5MHiMWFTiDBnf t4f2N+oA897yMdmY9afEdI1MbVBL5QgyRzJoAy1nu0aumTPDtH/gnZ55s2mVupgGC/wg +jhg43LUrS3S8sdZbBDq9w9vqSdpThH1daSpxJ1GmKuoYNmPwa6soG6oqh9VXqQOLQnv ycNQ== X-Forwarded-Encrypted: i=1; AJvYcCWXTgUFMfr9p6nfWxvItGni1RYemEOwcl1S3CjI0nI/GekeFuONO1JVcjnlPC5whEC6N/+QbThOFfzl9g==@sourceware.org X-Gm-Message-State: AOJu0Yyq1y2FWiWRs8goP4PVD7sCWytXkENZLN+5aDhGRGUtaqDlwQ8o RNIOuWA63NdbMBE6HqlCiro/Jvu4YQTHHHJm3zYpoeP5NYYrIh42PQhbBky5SoipQ/5CijoTNfl UUu8/QI39W5GfxjsWZzjQ8eVKP2MZTKd74b8qX2ys557o89XSVcUIWHgHssk= X-Received: by 2002:a05:6602:6019:b0:834:f33c:fcdc with SMTP id ca18e2360f4ac-834f7d7c1e6mr1474445639f.14.1728331100798; Mon, 07 Oct 2024 12:58:20 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEB5OAi2EF8yBkIF8Eyf54Xl9XjnbQReQEQKTiTMLqF3//K84hOuxaAueDZJHSwCjQuBxw9IQ== X-Received: by 2002:a05:6602:6019:b0:834:f33c:fcdc with SMTP id ca18e2360f4ac-834f7d7c1e6mr1474442839f.14.1728331100436; Mon, 07 Oct 2024 12:58:20 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:92c5::1000? ([2804:14d:8084:92c5::1000]) by smtp.gmail.com with ESMTPSA id ca18e2360f4ac-83503b2fc8csm138953939f.48.2024.10.07.12.58.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Oct 2024 12:58:19 -0700 (PDT) Message-ID: <59157ccb-69cd-4d23-9e39-89bb211583f8@redhat.com> Date: Mon, 7 Oct 2024 16:58:16 -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> From: Guinevere Larsen In-Reply-To: <86a5ffu3ij.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/7/24 4:17 PM, Eli Zaretskii wrote: >> Date: Mon, 7 Oct 2024 15:30:37 -0300 >> Cc: gdb-patches@sourceware.org >> From: Guinevere Larsen >> >>> And a more practical question: if I want to build GDB that will run on >>> GNU/Linux and should be able to debug Linux executables natively and >>> MS-Windows executables via gdbserver, which formats should I specify >>> with this new --enable-formats option? >> Linux uses elf files, and windows uses PE-coff (compiled when coff is >> requested), so you would need --enable-formats=elf,coff >> >> However, with the patch as-is in the list, any value you put in there >> (including --enable-formats=no, which would add nothing user selected) >> would compile support for elf and coff anyway, so there is no need to worry. >> >> Finally, if you aren't sure, the default behavior if the flag is to >> compile all readers, keeping with the old behavior. > I presume users and packagers will want to use this feature to avoid > compiling in stuff they will never need. The problem, as I see it, is > that it is hard to decide what to specify, and your answer to my > Linux+Windows question illustrates this very well. > > By contrast, the security benefits might not be interesting at least > to some. That is fine. As the documentation below points out, the default behavior is to add all readers just like GDB already does, so if a user does not find this feature compelling, they are free to ignore that it exists and continue using GDB as they have up until this point. > >>> See, I think these are the questions that the readers of the manual >>> will ask themselves, and we should have the answers there for them. >>> >> That's a reasonable point. I don't think we should need to document all >> targets, but I can see the value of documenting the main usage of the >> file format when describing the options, as a guideline for users >> running on mainstream platforms and not meant as an exhaustive list. I'm >> thinking of adding the following to the readme: >> >> `--enable-binary-file-format=FORMAT,FORMAT...' >> `--enable-binary-file-format=all' >>   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. The other possible options are: >>   * coff: Main format on windows systems. This is required to compile with >>     windows target support; >>   * dbx: (also known as a.out), is a legacy file format, this is >> recommended >>     if you know you will be dealing with this file format; >>   * elf: Main format of linux systems. This is heavily recommended when >>     compiling with linux support; >>   * macho: Main format on MacOS systems, this is heavily recommended >>     when compiling for those targets; >>   * mips: (also known as ecoff), this is the main file format for targets >>     running on MIPS CPUs. It is heavily recommended when supporting those >>     targets. >>   * xcoff: Main format of AIX systems, this is required to compile for AIX >>     targets and rs6000 CPUs. >> >> >> What do you think? > 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. 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. > > 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. My internet search couldn't find one very reputable source, but it seems that MacOS uses Mach-O format, and Windows uses PE/COFF format, the same as the default file format of the target. 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. -- Cheers, Guinevere Larsen She/Her/Hers