From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8EJLNi/7/2Z8IwEAWB0awg (envelope-from ) for ; Fri, 04 Oct 2024 10:26:55 -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=GD9P/S3G; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DA25A1E355; Fri, 4 Oct 2024 10:26:55 -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 1C1871E05C for ; Fri, 4 Oct 2024 10:26:55 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D93F6386D626 for ; Fri, 4 Oct 2024 14:26:54 +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 F0B05386D620 for ; Fri, 4 Oct 2024 14:26:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F0B05386D620 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 F0B05386D620 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=1728051992; cv=none; b=VFPZTTGOEXerDraeFuYcEgY2IKXPEmchbvMYxw8c7CQMyRJ7nbdSVnJCi7wULttY3DkIpWm/iekMGqh7uDmHNVOTvivUpxwoCJDmk2UCXbNo1NUOr2mXue76m2EYQUxxJsgbl8mlO7/B/O6h578PWIZshqBVEBn1Lf/tbyx3SsM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1728051992; c=relaxed/simple; bh=8TnKNal0cVZvrWRoormxxne9ld/l817rijkbsPzJKnI=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=czFKoypdMg+ruS3wIF0VspXtpo4RbEueX9Lv2sOT1OyWqRoC2zd0Av1CUqZ1UMpmCC5bAT+mzILp7GWSmt3vOfkF506ysiBHjeRkiuRI5aiTUJi4hfpOqz9KAt0GylUJPdtSFL4GJQOJE9c2ghAN/09uZJyuYcaLNjX33zDvlUI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1728051989; 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=6kh4yMDz7JjMFMVm8FIDdSfnjl7vMbUWC+S/2swWC4g=; b=GD9P/S3GvLOj9plXDsFIX8S7J07vTK8UJWeavHGGBKM8UTCZ5BMWvxDfC7HtdMfgxzN+tu F7DuVCDJQX6NcWQCHAsfNuy2ITHvIyX7PUJVCjm89ifty5JqZTbEtQ4vR/z0J/SxdpsjVa 5zCsfghLyki1VHNbSBYXhBBVErPVarc= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-629-AHkPN38ZPwmlMcwRhvmdjQ-1; Fri, 04 Oct 2024 10:26:28 -0400 X-MC-Unique: AHkPN38ZPwmlMcwRhvmdjQ-1 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-a8a8ee13b44so133993166b.2 for ; Fri, 04 Oct 2024 07:26:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728051987; x=1728656787; 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=6kh4yMDz7JjMFMVm8FIDdSfnjl7vMbUWC+S/2swWC4g=; b=P3nMyAnpFftYwUMi5NxpphQ+G8qs7D0tjuJs/oHNqVoMA/ED16g/VyjUS03l4Xv0/g ZLxn1zlZFUm1g2iJbBvGMjKcSi1QoaDxvatKuJuGH/pLS0EPCK8IdxhZ06t+fZ38fpED GV8WOlR7ygiTlNPBxSh4opHYnmfTSytfu1F/XzPQd9w1O25h3A+5MMv7thQDPA08Ca9l IX67/D2xgqGCpD9n5LKEbDLJ8nN8v70yYJcO1C7i11QKQc8vu9fk7+GBDRR1wzlmeayS jILdpPVuy5sTZTU8XlilgDa1f2OC6JOHEaCQn/4LCGMpcUm5pVySzuI1RQldVk7FPPC5 g66Q== X-Forwarded-Encrypted: i=1; AJvYcCVAtCfQJEcnOzDO9y+/oVqsdTq3nIqRiYWftRC6WUt01gVrLgBRTaDbV/omBOFQ7VsbRIuFjPGK+HgP2w==@sourceware.org X-Gm-Message-State: AOJu0YxzhCPIyOzPrC1Xw6X/qMUY+DgyKQBrSj52fEXvfkv1y1E1prBf WV/8NxQ+WyYbAfR8sqLqYM8v69R3jgvGnZXtbOqJqNJchqlSPyAsBhLtT7iIx+GqoFAs1ZZ1EgD a3cDP+3NiMaxSNGZI1iQ7XstUSUGTahZgVCuTMVdBnjiwFOukwGIF8jzjkec= X-Received: by 2002:a17:907:3e03:b0:a99:bb:735d with SMTP id a640c23a62f3a-a991c00e0ebmr294971566b.54.1728051987030; Fri, 04 Oct 2024 07:26:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGa+AdWPtvnYA/klIC2R1rnx8gpASrikle9La5UIqYgRDw5kx3/qG+OdtxZpB6p44SyN5SiBw== X-Received: by 2002:a17:907:3e03:b0:a99:bb:735d with SMTP id a640c23a62f3a-a991c00e0ebmr294968766b.54.1728051986621; Fri, 04 Oct 2024 07:26:26 -0700 (PDT) Received: from localhost (243.223.159.143.dyn.plus.net. [143.159.223.243]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a99103b32c1sm233333866b.133.2024.10.04.07.26.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Oct 2024 07:26:26 -0700 (PDT) From: Andrew Burgess To: Eli Zaretskii Cc: guinevere@redhat.com, gdb-patches@sourceware.org Subject: Re: [PATCH] gdb, configure: Add disable-formats option for configure In-Reply-To: <86ed4y1tgg.fsf@gnu.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> Date: Fri, 04 Oct 2024 15:26:25 +0100 Message-ID: <87bk00x7u6.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: >> 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? Yes. gdbserver supports far fewer target OSes than GDB itself, as far as I can tell it's Linux, netbsd, or Windows. Unlike GDB, gdbserver only every supports a single target. This makes sense as gdbserver only ever controls native processes running on the same machine as gdbserver itself. This is enforced at configure time, if we configure the binutils-gdb tree with --target not equal to --host then the gdbserver directory will be disabled, and we don't even attempt to build gdbserver. GDB splits target support into *-tdep.c and *-nat.c files. The *-nat.c file is for lower level, native target stuff, e.g. how do I create a new process, how do I read the registers. Then the *-tdep.c files are for higher level target specific stuff, e.g. setting up platform specific types, registering special frame unwinders, signal handling details, etc. gdbserver only needs to include the lower level knowledge, the equivalent of the *-nat.c files, though on the gdbserver side these files are called *-low.cc. Some code is shared between GDB and gdbserver in this area, but not everything. This can, and should be improved. But the high level logic, the *-tdep.c files, only live in GDB. When a target is compiled into GDB this causes the tdep files to get built in. Which nat files we build in depends on the --host configure option, that is, where is GDB (the program) going to run. > 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? The problem is that reading the file is only one part of the process. The target specific tdep file adds higher level knowledge on top of the file contents. I dug out an old windows machine and setup the following debug environment: on the windows machine I built gdbserver for x86_64-w64-mingw32, then on an x86-64 Linux machine I built GDB only with support for x86_64-redhat-linux. The source I was building from didn't include Gwen's patch, so all file formats are usable. GDB is able to connect to gdbserver, and can read the executable and libraries, and can extract the symbols. However, GDB gets the addresses for all symbols wrong. The reason for this can be found in windows_init_abi_common where we call set_gdbarch_so_ops. This call registers some callbacks that are used whenever GDB opens a library or executable. These callbacks can do things like fix up the objfile section addresses, which is exactly what's being done in this case. As the windows_init_abi_common is in windows-tdep.c, when this file is not compiled in, GDB doesn't really "understand" the executable file within a Windows context, and so the sections offsets are left as 0, and GDB gets all the symbol addresses wrong. So, I can disassemble instructions using an address and length, e.g. 'x/10i ADDRESS', or place breakpoints by address 'b *ADDRESS', but I can't do anything that relies on symbols, e.g. 'b main', or 'disassemble main'. In addition GDB isn't going to be able to backtrace correctly, skip function prologues, or any of that other good stuff. Out of interest, I also tried building GDB with only Linux support, and, using Gwen's patch, with only ELF file format support. My thinking was that, if previously GDB could read the file, but couldn't actually do anything useful with the symbols, then maybe we're no worse off if GDB just can't read the file at all... ...unfortunately, GDB segfault. I'll report this to Gwen separately. But in theory, we'd probably be better off if GDB didn't read the symbols from the file, given that GDB can't then figure out the correct addresses. > 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"? I agree with you about "target" having two components, the lower level stuff, and the higher level stuff. File format support, being able to read from file, only (I think) impacts higher level functionality. But just reading the file isn't (I claim) enough, we need the higher level functionality in order to really "understand" the file contents. My claim then is that being able to remove the file format support will actually make the GDB slightly better (in some cases) as GDB will no longer be able to read a file which it is then unable to correctly process the contents of. Thanks, Andrew