From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jMQ9Am5RI2eEiyAAWB0awg (envelope-from ) for ; Thu, 31 Oct 2024 05:44:14 -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=OitCCd6N; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D79281E5BC; Thu, 31 Oct 2024 05:44:13 -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 3B9D91E5BA for ; Thu, 31 Oct 2024 05:44:12 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9DAF83857BBF for ; Thu, 31 Oct 2024 09:44:11 +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 CB54F3858D33 for ; Thu, 31 Oct 2024 09:43:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CB54F3858D33 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 CB54F3858D33 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=1730367832; cv=none; b=WwL53pdP40GrBSGizipCmjQUtBKd0s8W/Swd/CVC4Y0rUhKNnYa1sEgJJqtVXit6Bhjn4aBYBYidw/v9rJGBFBLMMsHu1yk5u45cyH+v99Xy+RFAbeUe7/+dJwAIJi19qju863GJztDilrV8cGm9dAjA7fMM3QaBq0OqbffueIs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1730367832; c=relaxed/simple; bh=AjJEBX1TKUggQEPxjteh8pMC67HwxQX8TIY+WD0vnqE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=s8Hod7Vx8608wcUTNc5FNyjTBYNiEK1Rv2LOegM9ihI3Zbldz9w/lNqsk66pz+uNzjB2YtgX/KVW0BhcjoNi+NHMh9BXPWhXPlfMO539jra3Y08mLKNAN8n5leOk/2wigbBqz4bDp0LWPgYvDYNg3gy4/EDxjMyN6LDa5m/vAV0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1730367823; 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=MePVK0TykXARe3oZ2G9BTqwDDGhmyivifqLKVYftS1U=; b=OitCCd6NdN5UhQhPBHXM/qJR0PsuJvmQ+iVF8wmxysPw3jsjrnwGQgRbXS0mV1vDX9ZH+a yTRQ5zV1apB5KR9UQDLqxfZaWabvyjuzszz+XOaZyVa7GUhZo9Z5WBMh7dAyTVrRn7B5fS ROpT2GiK0zc5CaLhwB2XzH6ZeYKnNTs= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-652-UFEksDHcOw-W6RaKMMsPPQ-1; Thu, 31 Oct 2024 05:43:42 -0400 X-MC-Unique: UFEksDHcOw-W6RaKMMsPPQ-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-37d4a211177so379428f8f.0 for ; Thu, 31 Oct 2024 02:43:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730367821; x=1730972621; 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=MePVK0TykXARe3oZ2G9BTqwDDGhmyivifqLKVYftS1U=; b=DtoVK0Ngjxp4OBqqXn2AOCqB+spiGH3FE8hCwxdR8gxy7uBw8s9ua3gTOXGC4zLabo CcLNV5+lYDdOz5HY+wThL7WsqR2mjNgVw1YfEjxDf5xm+QFYj92vfRuu9uKQIUBdEcDE tau13rcwDuAmgT2bxVqyqTGb17gaI99jrqqrRuPIve3Y3Rwm1a/9giNDrqX+WPx5M55p usm4thyaWKvOu80hgMem1deY6mxZ2mFluMOtPSIPvPQgbpnDectl/R18FWi/t5vF9T4S x38fU8Ltp9bsYoYlQh0wLzqpvw1ivvoomw8NuYuC7qR6gIzelphOi3W0ARrAE3zHGlGS h1BA== X-Gm-Message-State: AOJu0YzNhg0OD6lhyDUB51qnkMd+msa/yke2DCpDLkuDXPB41Ppv0CRR KtNsb14qBg9DO2SRaCQozNKLHWcVnlKlC3aZZ/tfK2+A1ToueVuBHRKgewn12HFcvJOY6QE62tv 5EMSkprjFpirXAxMPA0X7qK95OI3jc78JWSpojZ41VYKxJooL8iF/tEbmnew= X-Received: by 2002:adf:ec85:0:b0:37d:53a7:a635 with SMTP id ffacd0b85a97d-380611fe4e3mr12932254f8f.51.1730367820821; Thu, 31 Oct 2024 02:43:40 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEwZIOWl1WdbgKnShsPZDZ2Ug7rz1FzVinV3qa4sbT5jlDcpFv6AH8CodTcLdAh6ZWIpbmI0g== X-Received: by 2002:adf:ec85:0:b0:37d:53a7:a635 with SMTP id ffacd0b85a97d-380611fe4e3mr12932237f8f.51.1730367820374; Thu, 31 Oct 2024 02:43:40 -0700 (PDT) Received: from localhost (197.209.200.146.dyn.plus.net. [146.200.209.197]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-381c113e068sm1555867f8f.71.2024.10.31.02.43.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Oct 2024 02:43:40 -0700 (PDT) From: Andrew Burgess To: Kevin Buettner Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv5 3/3] gdbserver: pass osabi to GDB in more target descriptions In-Reply-To: <20241030192823.00ce5930@f40-zbm-amd> References: <20241030192823.00ce5930@f40-zbm-amd> Date: Thu, 31 Oct 2024 09:43:39 +0000 Message-ID: <87o730txo4.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 Kevin Buettner writes: > 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 Thanks for the reviews. I'll give this some additional time to see if anyone else wants to comment. Thanks, Andrew