From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ugXXGMxJ/WbHuz4AWB0awg (envelope-from ) for ; Wed, 02 Oct 2024 09:25: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=XbsXTlcB; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4B7191E353; Wed, 2 Oct 2024 09:25: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 977A31E05C for ; Wed, 2 Oct 2024 09:25:30 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E4CAD38650DD for ; Wed, 2 Oct 2024 13:25:29 +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 CED333858424 for ; Wed, 2 Oct 2024 13:25:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CED333858424 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 CED333858424 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=1727875511; cv=none; b=KEmxVi3u9hanqDvrOA7fiCh4yAavkVBfyxsXa6DkHThICI0OeuKkt0LapV+jRexAr7a5hcvlolw1p4UUanhA/RDmrB91H9CeeYYxuhn/32MkvVYy9etSY/lQvOe1Vu6VdCtrr8BaJ8kaVQK0MOB0ID1lkfr/JcS6ivZOKTKtROg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1727875511; c=relaxed/simple; bh=SBiig5KCtv7s7LB98Z0Hbzb4UQ32g12WTUDZdUtQRmI=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=CT0Xz73I8IVpuZuyLLJA8XvBQaKg1YPgA/Bx+LayrMeQr0EqWScg7veZj6GAMA5JqOKzHsDcCHkk/7ZXqu/ASVioKIuvz/pli0mS0R/hjq/6JoHaWZKQbAEG/0dV8jp5VLRrAXbr799LbzfmKxYcbbOOpd8BUUTJbOXYQVSESKY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1727875509; 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: in-reply-to:in-reply-to:references:references; bh=6UHz1hwEXTypwyZ2iJ9Gje2BTFncsXQrtb5sB5MbIrA=; b=XbsXTlcBR26OBHhWoiJPHTMjuc+SBFD2lD9poFGlYdrToi2kEETjkiRxGwlgUi+VX0tKP5 oLuxs8Tk2x77USmeJ67alMaXFfD6WJAyF8EdUA0gpzF2uJuNyeGxwczogTdDpMIVpfFMQX XHD0Z0I6xEtorHt1KJRVy8EHT+Ml+dg= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-387-a1mxODiIOAC6RrWs6Zy33w-1; Wed, 02 Oct 2024 09:25:08 -0400 X-MC-Unique: a1mxODiIOAC6RrWs6Zy33w-1 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-a8d34e41915so427725866b.2 for ; Wed, 02 Oct 2024 06:25:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727875507; x=1728480307; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6UHz1hwEXTypwyZ2iJ9Gje2BTFncsXQrtb5sB5MbIrA=; b=I6pdDroGOoBmWz4ACsgxhYmgdJr5iDhijWiWYgDzQaoCy6StsUI4cnCtIaG5J7LLH/ ujceGIcDkfhRIkiTKXTn6m2/UUkxkOA7Z52Bl1JWZd6BJ1FsvQgWxkWuz116tzaTmfGS xMX/dNNJey5AOf6d3a8mjO9kSDOxY1JxSjo0+OsmzyQUY6sIfqmNtzsUqoyKdYM0ZJeC QFRp20+MppqEw8nj3tW9dUAdaq4TjKfV6vuFVieVvSNYrglGKHAsvWsfSwPSIH8bwRk9 voTDWgoAbIDwxNDdoubxpmof/Hpr272l/XxKoeyIgoHzPHj3HWCHtb4p7+eCF8073K/y 3MDQ== X-Gm-Message-State: AOJu0Yyp1D1pNcqgHjNveswwnajMulTzFH7aaZB3Lpr2PwlOzzg315Uc i41zljARn8UCrpGd0DaggkT5gCArQn2nsb2HJoM/xrvsncB3RNHi1bCrD/8iAbmTjOHLRY906lk QftqM1hdGh090MfKI35+w8LtOk4PCA6YffJXTDhbAMFkjE0QpevyUmareHhc= X-Received: by 2002:a17:907:3d91:b0:a7a:9fe9:99e7 with SMTP id a640c23a62f3a-a98f8372a3cmr262343966b.41.1727875507221; Wed, 02 Oct 2024 06:25:07 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFfRIpSzSSV0NtV1LGtj6BKwchtMERl+4T4NvjeVQmpc3m3puQBaFFxuX7AM4LZjW4zfpQTXg== X-Received: by 2002:a17:907:3d91:b0:a7a:9fe9:99e7 with SMTP id a640c23a62f3a-a98f8372a3cmr262341466b.41.1727875506778; Wed, 02 Oct 2024 06:25:06 -0700 (PDT) Received: from localhost (243.223.159.143.dyn.plus.net. [143.159.223.243]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a93c297c2c7sm859042466b.180.2024.10.02.06.25.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Oct 2024 06:25:06 -0700 (PDT) From: Andrew Burgess To: Eli Zaretskii , Guinevere Larsen Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb, configure: Add disable-formats option for configure In-Reply-To: <8634llaay5.fsf@gnu.org> References: <20240925175340.1850969-1-guinevere@redhat.com> <86msjvars2.fsf@gnu.org> <865xqi9sak.fsf@gnu.org> <8634llaay5.fsf@gnu.org> Date: Wed, 02 Oct 2024 14:25:05 +0100 Message-ID: <87setey6vi.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Eli Zaretskii writes: >> Date: Thu, 26 Sep 2024 18:03:05 -0300 >> Cc: gdb-patches@sourceware.org >> From: Guinevere Larsen >> >> > My point was that the manual doesn't clarify these issues. It left me >> > confused. >> > >> >>> Maybe I'm confused, but if I am, it means we lack some important >> >>> information in the manual which would clarify this. >> >> Maybe more clarity would be helpful, but I don't think these issues have >> >> to do with my patch itself, so I think this should be further >> >> improvement for documentation rather than having to fix it in this patch. >> > You may be right, but without clarifying this whole issue I cannot >> > decide whether your additions about this are okay or not. So I think >> > we have no choice but to clarify those other aspects together with >> > this review, even if just in principle. >> I hope I clarified enough in this email to allow you to judge my changes >> on their own, and a later unrelated patch can fill in the missing >> information, since the changes really aren't related to enable-targets >> and it was my mistake to parse them there instead of just seeing which >> tdep files are compiled in and need a file format. > Hi Eli, I was catching up on this thread and though I could help by expanding the docs on the --enable-targets and --target flags, but I was confused by one of your questions below... > Unfortunately, I'm still in the dark here. I'd appreciate if you or > someone else who understands the way we deal with targets in all the 3 > scenarios -- native debugging, cross-debugging, remote debugging -- In my mind cross-debugging IS remote debugging, I don't understand what the distinction would be. Let's build up some examples to work through why I hold the above belief. What follows are GDB configure lines and then a description of what capabilities I think that GDB would have. This ignores the work Gwen has done, as you say, lets get the docs for --target and --enable-targets sorted first, then Gwen's work can sit on top of that: (1) ./configure This GDB will be able to run on the build host and will support debugging the build host only. This GDB will support remote debugging, but only to targets that are the same as the build host, i.e. same architecture and same OS. (2) ./configure --target=<1> Assuming that <1> doesn't match the build host, then this GDB will be able to run on the build host but will not be able to debug native processes. In fact the native target support will not even be compiled into GDB. This GDB will be able to remote debug inferior's running on a remote host that matches <1>. (3) ./configure --host=<1> Throwing this one in just for completion. Assuming that <1> doesn't match my local build machine, this is going to cross-build GDB to run on a <1> host machine. GDB will be able to debug native processes on the <1> host, and GDB will also be able to remote debug processes on machines that are also of <1> type. (4) ./configure --host=<1> --target=<2> Assuming that <1> does not match my local build machine, and that <2> doesn't match <1>, this is going to cross build GDB to run on machines of type <1>, and GDB will only be able to remote debug targets of type <2>. As with case (1) native target support isn't going to be built into GDB. What you'll notice in all of the above is that --target only allows a single target type to be specified. If we want GDB to support multiple targets then --enable-targets can be used. This option takes a list of targets which are built into GDB in addition to the --target value. So: (5) ./configure --enable-targets=<1>,<2>,<3> Without an explicit --target option this is similar to case (1) above. GDB will run on the build host and can debug either natively, or remotely, inferiors running on machines that are the same as the build host. In addition, assuming <1>, <2>, and <3> are all different from the build host, GDB will be able to remote debug targets matching <1>, <2>, and <3>. Of course, we are free to use `--enable-targets=all' which adds support for all known targets to GDB. In this case the build host type is effectively passed twice, once implicitly in the `--target' option, and then again as a member of `--enable-targets=all', but that's OK, the configure scripts can cope with this, and we just build everything into GDB. One important detail is that there is no real difference from specifying a target via --target vs via --enable-targets. Consider this case: (6) ./configure --host=<2> --target=<1> --enable-targets=<2> This GDB will run on <2> and will be able to debug native processes on <2>. In addition GDB will be able to remote debug <1> and <2>. This is equivalent to: (7) ./configure --host=<2> --enable-targets=<1> Without an explicit `--target' option the configure script assumes that the target should match the host, then we add the ability to also remote debug <1>. > could explain how this stuff works (and perhaps how it should work > ideally, if what we have is not ideal/correct), and then we could take > it from there. This all seems OK to me. If you agree then I'm happy to try and tighten up the docs a little to (hopefully) better explain things. > We could, of course, just go with your changes disregarding these > larger issues, but I think clarifying them will also help us > understand better this new feature and make sure it is designed and > implemented correctly. I think Gwen's changes are broadly fine (I have some minor nits), but I agree with you, Eli, that we should try to get the docs into a state where this makes sense. I know you have a huge amount of experience with configuring / building GNU software, so if you can't read the docs and understand this, then it feels like a less experienced user is going to be even more confused. > OTOH, if I'm the only one who doesn't fully understand this stuff, and > everyone else agrees with the suggested changes as they are, feel free > to ignore me. I certainly don't think you should be ignored, but I'd like to give my attempt at explaining the motivation for this work, and why I think this is OK (once it's documented well enough). 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. If you can give your thoughts on what I wrote about --target and --enable-targets= above, then I'll try to draft a patch that improves the docs in this area, then Gwen can update on top of that, which hopefully will bring some clarity. Thanks, Andrew [1] In some cases it might be possible to connect to a remote target and perform basic (address based) debugging even if support for the target OS is not available in GDB. GDB would need to have support for the target architecture compiled in (which is not always the case), and GDB still might struggle to access inferior state in some cases. That anything works in this case is, I feel, more by luck than design, so I don't really consider this "working".