From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +DKNHnPrImerKiAAWB0awg (envelope-from ) for ; Wed, 30 Oct 2024 22:29:07 -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=RI4C7hzx; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4F7F21E5A1; Wed, 30 Oct 2024 22:29:07 -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 9C3F91E37A for ; Wed, 30 Oct 2024 22:29:06 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3BCC23858429 for ; Thu, 31 Oct 2024 02:29:06 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id C90153858D3C for ; Thu, 31 Oct 2024 02:28:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C90153858D3C 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 C90153858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730341714; cv=none; b=KHhh4RqRpNhQe2X5K3MBW90mlkp+rmS2axl9kIMNTxb6a7l26hvX1RzRsQdDHWVn+hXl/vl2JO42QICDmzkAD4EQPGIe5b50EDoWa+O1RjF2A7aeSF9N+XMqouKFyde1AejQX2xzkMypzC9y33vrZRXRONK9f00mxp+8lcPU60c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730341714; c=relaxed/simple; bh=917M7ZR6mkMYKdOLLwmVrkoGMYEIxCfcVlsBAMyO1iI=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=RITUdqWU1G9GeT8GMHE7xyZRkVGsuhDZO6ckiJc/9ni/KzIiWQKe5LnkOV5BXFrX45RrVep11hSqc+Ls0j+yRjkgvNc1/lUEOFfwM23qS8urchGycccib76cZ01zFq6DN+3O+Og2z6dX1c5dmds3IvOi1PmQmCMBoyy/SbEMN34= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1730341711; 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=/JFiS5RKqXeSdp+mDqTmAp/Tr7KXJS4KYaq7W+SkEJA=; b=RI4C7hzxASS54KAsm1INxjQVKkPJwoPGBH0qgsOasQ22vCmsqQ0fFSEUtFQp0F5FyQV5wD vYfTp5xn3lTKM6dWPRe9w2aaALWfhp9qlNo6LVxtfDgZA8ZgSByWbQuCOTf9hHe0MZPvej eaOyLE9TXxbXCZr4jn9lr5h1ryC5H7E= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-196-eUWf6PjjMEOczj7c-2bH_w-1; Wed, 30 Oct 2024 22:28:30 -0400 X-MC-Unique: eUWf6PjjMEOczj7c-2bH_w-1 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2786E19560BA for ; Thu, 31 Oct 2024 02:28:29 +0000 (UTC) Received: from f40-zbm-amd (unknown [10.22.64.38]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 45A8119560A2; Thu, 31 Oct 2024 02:28:28 +0000 (UTC) Date: Wed, 30 Oct 2024 19:28:23 -0700 From: Kevin Buettner To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv5 3/3] gdbserver: pass osabi to GDB in more target descriptions Message-ID: <20241030192823.00ce5930@f40-zbm-amd> In-Reply-To: References: Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Sun, 27 Oct 2024 20:07:42 +0000 Andrew Burgess wrote: > Problem Description > ------------------- > > On a Windows machine I built gdbserver, configured for the target > 'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with > support for all target (--enable-targets=all). > > On the Windows machine I start gdbserver with a small test binary: > > $ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe > > On the GNU/Linux machine I start GDB without the test binary, and > connect to gdbserver. > > As I have not given GDB the test binary, my expectation is that GDB > would connect to gdbserver and then download the file over the remote > protocol, but instead I was presented with this message: > > (gdb) target remote 192.168.129.25:54321 > Remote debugging using 192.168.129.25:54321 > warning: C:\some\directory\executable.exe: No such file or directory. > 0x00007ffa3e1e1741 in ?? () > (gdb) > > What I found is that if I told GDB where to find the binary, like > this: > > (gdb) file target:C:/some/directory/executable.exe > A program is being debugged already. > Are you sure you want to change the file? (y or n) y > Reading C:/some/directory/executable.exe from remote target... > warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. > Reading C:/some/directory/executable.exe from remote target... > Reading symbols from target:C:/some/directory/executable.exe... > (gdb) > > then GDB would download the executable. > > The Actual Issue > ---------------- > > I tracked the problem down to exec_file_find (solib.c). The remote > target was passing an absolute Windows filename (beginning with "C:/" > in this case), but in exec_file_find GDB was failing the > IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as > relative. > > The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that > the file system kind was "unix", and as the filename didn't start with > a "/" it assumed the filename was not absolute. > > But I'm connecting to a Windows target and 'target-file-system-kind' > was set to "auto", so GDB should be figuring out that the target > file-system is "dos-based". > > Looking in effective_target_file_system_kind (filesystem.c), we find > that the logic of "auto" is delegated to the current gdbarch. However > in windows-tdep.c we see: > > set_gdbarch_has_dos_based_file_system (gdbarch, 1); > > So if we are using a Windows gdbarch we should have "dos-based" > filesystems. What this means is that after connecting to the remote > target GDB has selected the wrong gdbarch. > > What's happening is that the target description sent back by the > remote target only includes the x86-64 registers. There's no > information about which OS we're on. As a consequence, GDB picks the > first x86-64 gdbarch which can handle the provided register set, which > happens to be a GNU/Linux gdbarch. > > And indeed, there doesn't appear to be anywhere in gdbserver that sets > the osabi on the target descriptions. Some target descriptions do have > their osabi set when the description is created, e.g. in: > > gdb/arch/amd64.c - Sets GNU/Linux osabi when appropriate. > gdb/arch/i386.c - Likewise. > gdb/arch/tic6x.c - Always set GNU/Linux osabi. > > There are also some cases in gdb/features/*.c where the tdesc is set, > but these locations are only called from GDB, not from gdbserver. > > This means that many target descriptions are created without an osabi, > gdbserver does nothing to fix this, and the description is returned to > GDB without an osabi included. This leaves GDB having to guess what > the target osabi is, and in some cases, GDB can get this wrong. > > Proposed Solution > ----------------- > > I propose to change init_target_desc so that it requires an gdb_osabi > to be passed in, this will then be used to set the target_desc osabi > field. > > I believe that within gdbserver init_target_desc is called for every > target_desc, so this should mean that every target_desc has an > opportunity to set the osabi to something sane. > > I did consider passing the osabi into the code which creates the > target_desc objects, but that would require updating far more code, as > each target has its own code for creating target descriptions. > The approach taken here requires minimal changes and forces every > user of init_target_desc to think about what the correct osabi is. > > In some cases, e.g. amd64, where the osabi is already set when the > target_desc is created, the init_target_desc call will override the > current value, however, we should always be replacing it with the same > actual value. i.e. if the target_desc is created with the osabi set > to GNU/Linux, then this should only happen when gdbserver is built for > GNU/Linux, in which case the init_target_desc should also be setting > the osabi to GNU/Linux. > > The Tricky Bits > --------------- > > Some targets, like amd64, use a features based approach for creating > target_desc objects, there's a function in arch/amd64.c which creates > a target_desc, adds features too it, and returns the new target_desc. > This target_desc is then passed to an init_target_desc call within > gdbserver. This is the easy case to handle. > > Then there are other targets which instead have a fixed set of xml > files, each of which is converted into a .dat file, which is then used > to generate a .cc file, which is compiled into gdbserver. The > generated .cc file creates the target_desc object and calls > init_target_desc on it. In this case though the target description > that is sent to GDB isn't generated from the target_desc object, but > is instead the contents of the fixed xml file. For this case the > osabi which we pass to init_target_desc should match the osabi that > exists in the fixed xml file. > > Luckily, in the previous commit I copied the osabi information from > the fixed xml files into the .dat files. So in this commit I have > extended regdat.sh to read the osabi from the .dat file and use it in > the generated init_target_desc call. > > The problem with some of these .dat base targets is that their fixed > xml files don't currently contain any osabi information, and the file > names don't indicate that they are Linux only (despite them currently > only being used from gdbserver for Linux targets), so I don't > currently feel confident adding any osabi information to these files. > An example would be features/rs6000/powerpc-64.xml. For now I've just > ignored these cases. The init_target_desc will use GDB_OSABI_UNKNOWN > which is the default. This means that for these targets nothing > changes from the current behaviour. But many other targets do now > pass the osabi back. Targets that do pass the osabi back are > improved with this commit. > > Conclusion > ---------- > > Now when I connect to the Windows remote the target description > returned includes the osabi name. With this extra information GDB > selects the correct gdbarch object, which means that GDB understands > the target has a "dos-based" file-system. With that correct GDB > understands that the filename it was given is absolute, and so fetches > the file from the remote as we'd like. The approach that you've taken makes sense to me, but I'm not an expert in this area. Therefore, I don't feel comfortable giving an "Approved-by" for this particular patch. That said, I don't think it makes sense for it to languish on the mailing list, so I recommend that you approve it if there are no other comments within a week or so. Reviewed-by: Kevin Buettner