From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39459 invoked by alias); 17 Jan 2020 21:46:06 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 39392 invoked by uid 89); 17 Jan 2020 21:45:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=HX-detected-operating-system:Genre, HX-detected-operating-system:recognized, HX-detected-operating-system:details, H*f:sk:763defc X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Jan 2020 21:45:48 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1isZR3-0004NO-Ev for gdb@sourceware.org; Fri, 17 Jan 2020 16:45:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52113) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1isZQz-0007mM-4f for gdb@gnu.org; Fri, 17 Jan 2020 16:45:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1isZQx-0004K9-Gs for gdb@gnu.org; Fri, 17 Jan 2020 16:45:41 -0500 Received: from mx2.freebsd.org ([2610:1c1:1:606c::19:2]:17540) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1isZQx-0004JK-DV for gdb@gnu.org; Fri, 17 Jan 2020 16:45:39 -0500 Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 04F83977BD; Fri, 17 Jan 2020 21:45:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47zvkT5fbHz484B; Fri, 17 Jan 2020 21:45:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-7.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 3C8C510272; Fri, 17 Jan 2020 21:45:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: mode processor mode switch To: Pedro Alves , Luis Machado , =?UTF-8?Q?Jirka_Koutn=c3=bd?= , gdb@gnu.org References: <763defc1-90ae-ceda-61db-493ec81ca36d@linaro.org> From: John Baldwin Openpgp: preference=signencrypt Message-ID: Date: Fri, 17 Jan 2020 21:46:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2610:1c1:1:606c::19:2 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00031.txt.bz2 On 1/16/20 10:52 AM, Pedro Alves wrote: > On 1/16/20 2:51 PM, Luis Machado wrote: >> Hi, >> >> On 1/14/20 8:58 AM, Jirka Koutn=C3=BD wrote: >>> Hello, >>> >>> I have a 32-bit elf executable which at some point switches to long mode >>> (kernel is 64-bit). Is there a way to tell gdb about the .code32/64 >>> directives? Because expectedly the switch messes up disassembly and >>> stepping. >>> >>> Thank you >>> Jirka >>> >> >> Unfortunately i don't think there is a good way to achieve this with the= current implementation. >> >> You could teach GDB about the quirks in the architecture, but it sounds = better to have a more general solution. >> >> I'm working on making this more flexible though, since i have a need to = make the architecture information per-thread, at least the target descripti= on with the registers and types. >> >=20 > For x86-64 in particular, I think the ideal solution would be for > the remote target to always report the widest mode it supports, > which would be 64-bit, and then do the 32-bit/16-bit modes > presentation all on the gdb side (i.e., user-visible 32-bit on > top of 64-bit description). Mode switching would not change the remote > target description. This is unlike the current architecture where a > remote server reports a 32-bit description for a 32-bit process even > if the remote server is actually running on a 64-bit machine. I think this is the way to go, but you might still need some way to specify the mode. I'm not quite sure what qemu does, but for a gdb stub I've worked on for bhyve (a KVM-like hypervisor in FreeBSD), it always reports the architecture as 64-bits but checks various control registers when resolving virtual addresses for the 'm' and 'M' protocol commands. --=20 John Baldwin