From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2Kt1DVxcM2ccXS8AWB0awg (envelope-from ) for ; Tue, 12 Nov 2024 08:47:08 -0500 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=Uu2jmj8s; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 259131E11F; Tue, 12 Nov 2024 08:47:08 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 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_MED 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 37F151E11C for ; Tue, 12 Nov 2024 08:47:07 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D6B0C3858C32 for ; Tue, 12 Nov 2024 13:47:06 +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 DE7133858C98 for ; Tue, 12 Nov 2024 13:46:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DE7133858C98 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 DE7133858C98 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=1731419207; cv=none; b=Fu34PD5yPFH3pSvte6w0PV3QBLYiA5JmnQRSZKUKULbbyZ1lNQqkJ+SBpd4vpXVhCvaNBT9tyr+hDPHtuqvUW75wrTiV7Nn5g0zRM/VqemuIMxdO4uUFJ2O50v+DJeqZQM5ABNI6nRDCIm3CQN5MBJBfUJEYYLsr+ypE9tSceMc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1731419207; c=relaxed/simple; bh=TRyK1BjRHxQTRrzGXjLkjLP7AkEX+pSZKPe1VHge6u8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=PJZUw+k6g+eIi+MQn2oc4LMfnyP+yHpYuA7vLfD1HQbAI5kc1+8NqfYfk+qi5rYhk1VlDAq3t8UMNJb7ZwZNMO2OvFdGG5nofdLqKDgWH5s+kbf9OdxNxSv7E3X8NXhHqlNdxgzNC6yNoZ+VMC6HsL9v7gR1gDxWy6rlRzRPRx0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1731419203; 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=Dj9ZM6PE00CaHO/7yi1mZ6rasE9fGqfHR7+q288q2Wg=; b=Uu2jmj8s6DyQBHp0mZ6spmp0dTm7Bo6zqcJzWNZtE3I+RkWJ/Ow5v39ZzPMYmzADUC0ffK gQBxQP3CM+2wq/TiwfH+nZdqNVncAj9A6rXF3kjNFu/BXI2t0kjWQgoEXAirieg6f/NGs5 9rp+d5U0tFj9LSFyhkSAX1zruSQEYpE= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-391-znxHJab0NDSc7yxcEBIawA-1; Tue, 12 Nov 2024 08:46:42 -0500 X-MC-Unique: znxHJab0NDSc7yxcEBIawA-1 X-Mimecast-MFC-AGG-ID: znxHJab0NDSc7yxcEBIawA Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4315ad4938fso39320795e9.0 for ; Tue, 12 Nov 2024 05:46:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731419201; x=1732024001; 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=Dj9ZM6PE00CaHO/7yi1mZ6rasE9fGqfHR7+q288q2Wg=; b=nMAGG8Rks6wnSb+86c+jxIluzX/s+3f2nqM2gRLU+BPmbWviOvoVj20NtxLKfFN0Pq MTdIlR9HNN7qsFXMzrM9LByHJgHbOizIH3uXpxS1RYDXDS03bTZf6xK8/AWL6IT5hUUB gQA/idOCZ9Hf/Lx152aAnv+KazMZMP5lb3LhW9tvXCsV8o07tnvHyLvv6N0cEd/zBGLN Pp50Z2Iz7ic94deTwbj24BrZOFgqLguBC48Ogbvdd9C1IGEXoZhbOghVXUVJKP788Qs3 g5sypBTHuZ96g5h//6/X+OlDejMMD1B0QgzPwUXiSKT+AaTvd8uDrBccH34Pm6R+qYxw fQcg== X-Gm-Message-State: AOJu0Yz2D3EdRZKDUztHp04g1vDzXgwNHrix2mKF4BKzZrTKV1+jjNZq 4lUuil1wChZuPc82IoHg8wuZSKLbRkw8yBzK371R9x+ceSu0IUqYsl/EvMP1pTAUQt1+Iu0S8Sa QGCwJK0CczZIfkGewqMlTul80+U2Kh8b3v04ySgAh2EWF0IVlPvj0waWAj76Gey47Hl8= X-Received: by 2002:a05:6000:1f8f:b0:37d:52b5:451e with SMTP id ffacd0b85a97d-381f186fc20mr14139702f8f.33.1731419200965; Tue, 12 Nov 2024 05:46:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IF2shA548mBQnkT5N4ZqCSxH8yK1jgSiirlEQrdzzR5VkicYQohVaKQb5FQ6zb7blCilgx6ow== X-Received: by 2002:a05:6000:1f8f:b0:37d:52b5:451e with SMTP id ffacd0b85a97d-381f186fc20mr14139679f8f.33.1731419200455; Tue, 12 Nov 2024 05:46:40 -0800 (PST) Received: from localhost (197.209.200.146.dyn.plus.net. [146.200.209.197]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-381ed9f8f0asm15877544f8f.79.2024.11.12.05.46.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Nov 2024 05:46:40 -0800 (PST) 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: <87o730txo4.fsf@redhat.com> References: <20241030192823.00ce5930@f40-zbm-amd> <87o730txo4.fsf@redhat.com> Date: Tue, 12 Nov 2024 13:46:39 +0000 Message-ID: <87r07gpnsw.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Hyqv03i9fmGys3gNd8p18KCnD3SprXaGrR_c60SRQo8_1731419201 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 Andrew Burgess writes: > 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. I've gone ahead and pushed this series now. Thanks, Andrew