From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9427 invoked by alias); 21 Jan 2020 12:56:42 -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 9417 invoked by uid 89); 21 Jan 2020 12:56:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=BAYES_05,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=H*Ad:U*gdb, HX-Spam-Relays-External:4864, presentation, H*r:4864 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; Tue, 21 Jan 2020 12:56:31 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1itt54-0001RP-2u for gdb@sourceware.org; Tue, 21 Jan 2020 07:56:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54103) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1itt53-0004m6-L4 for gdb@gnu.org; Tue, 21 Jan 2020 07:56:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1itt52-0001Qp-89 for gdb@gnu.org; Tue, 21 Jan 2020 07:56:29 -0500 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]:44382) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1itt52-0001Pz-3O for gdb@gnu.org; Tue, 21 Jan 2020 07:56:28 -0500 Received: by mail-qt1-x842.google.com with SMTP id w8so2436412qts.11 for ; Tue, 21 Jan 2020 04:56:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0iC8pyiIyqF9ekOhfghkFmKbSmuAHXpqu37j1YEx0us=; b=O7jB4WPMx6XGiY8Vo0x0bp6nYM35TqRrCb3F5ceswjZmgwVwbNkcH8VYqTP+4NE80Q o65/rVDDpvTb+I63ICI47xWPJhvL5yA07MSlWSCy9qNL1RItzN3lgBm/1teFvAht2XO9 qM5PuaZaICu69TM3XXDOFxyC/r9iZeU76p5NlrVt0Kl9wtbdHMdkZJ5vz8ve17L+T+Zh w7e1IQZ8AbhFX3h2GW9aj0VKXO4c1APrO2kKIUabvIqIupCW3pxtbcXgkWx92OzeWrTI BxzRSvDcwX/AFRQg42hb3+kN4IhFtvzF5pe/XEPNScXkJXkdUN95d5QziXwF7cJb4GNS vPcQ== MIME-Version: 1.0 References: <763defc1-90ae-ceda-61db-493ec81ca36d@linaro.org> In-Reply-To: From: =?UTF-8?Q?Jirka_Koutn=C3=BD?= Date: Tue, 21 Jan 2020 12:56:00 -0000 Message-ID: Subject: Re: mode processor mode switch To: John Baldwin Cc: Pedro Alves , Luis Machado , gdb@gnu.org X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::842 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2020-01/txt/msg00036.txt.bz2 Erm hey guys, thanks for all your responses. I found out that it works if instead of inline assembly I just make a separate .S file and compile with 'as -m32 -g' and then link with gcc. fre. 17. jan. 2020 kl. 21:45 skrev John Baldwin : > 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 > description with the registers and types. > >> > > > > 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 speci= fy > 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. > > -- > John Baldwin >