From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71181 invoked by alias); 16 Jan 2020 18:52:40 -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 71164 invoked by uid 89); 16 Jan 2020 18:52:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 spammy=HTo:U*gdb, jirka, Jirka, H*f:sk:dW7Nxji 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; Thu, 16 Jan 2020 18:52:29 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1isAFo-0008LJ-5k for gdb@sourceware.org; Thu, 16 Jan 2020 13:52:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38167) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1isAFn-0002sx-OS for gdb@gnu.org; Thu, 16 Jan 2020 13:52:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1isAFj-0008I4-73 for gdb@gnu.org; Thu, 16 Jan 2020 13:52:27 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:20320 helo=us-smtp-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1isAFj-0008HY-3j for gdb@gnu.org; Thu, 16 Jan 2020 13:52:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579200742; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BkJG1G8vlza5BS/79MKhBYelnsIusiscl99qt693r7s=; b=Mby1axqBD0ZZseO8mb9ne4a8nhmDBq+Us4z9L7sG+KC4AAaWT47ttjDsgJei2Q+2IOSMNQ h+06dJWoppPyy0lPIdL4NtWBDvUDHZRTzt7vEkA2yPzsC1ydxjVbmI/32M/o58P4PtvFUk Ou+qCBz0BPUns/KkBz3hZAwgyLyg/XI= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-102-gitGbpGZOXWH4ZXvzOPW0g-1; Thu, 16 Jan 2020 13:52:18 -0500 Received: by mail-wr1-f70.google.com with SMTP id z10so9503641wrt.21 for ; Thu, 16 Jan 2020 10:52:18 -0800 (PST) Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id g21sm369171wmh.17.2020.01.16.10.52.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 10:52:16 -0800 (PST) Subject: Re: mode processor mode switch To: Luis Machado , =?UTF-8?Q?Jirka_Koutn=c3=bd?= , gdb@gnu.org References: <763defc1-90ae-ceda-61db-493ec81ca36d@linaro.org> From: Pedro Alves Message-ID: Date: Thu, 16 Jan 2020 18:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <763defc1-90ae-ceda-61db-493ec81ca36d@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 205.139.110.120 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-SW-Source: 2020-01/txt/msg00025.txt.bz2 On 1/16/20 2:51 PM, Luis Machado wrote: > Hi, >=20 > 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 >> >=20 > Unfortunately i don't think there is a good way to achieve this with the = current implementation. >=20 > You could teach GDB about the quirks in the architecture, but it sounds b= etter to have a more general solution. >=20 > I'm working on making this more flexible though, since i have a need to m= ake the architecture information per-thread, at least the target descriptio= n 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. Thanks, Pedro Alves