From patchwork Tue Jun 20 09:20:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 21128 Received: (qmail 103075 invoked by alias); 20 Jun 2017 09:20:45 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 103041 invoked by uid 89); 20 Jun 2017 09:20:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:4689, eip X-HELO: mail-io0-f172.google.com Received: from mail-io0-f172.google.com (HELO mail-io0-f172.google.com) (209.85.223.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Jun 2017 09:20:42 +0000 Received: by mail-io0-f172.google.com with SMTP id i7so80470588ioe.1 for ; Tue, 20 Jun 2017 02:20:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=CxpDGiP8hyb4PSY0E7L47g9o/rR43B9P5MWKYZrn7mY=; b=O/vwdo7F0YFWONspo6qcyEKZkWl2eZH7gpPNywU8E2JvPhPyVyT25STyZfd/h8mTg9 LHSQYqoMBrRJXd2tQTn32vySzBCkx7JCm2ubpfEVUukSKso+142dItp06VZW9Fzq7IMS FIXB9JPjEW8Mti6uzlB1SSWRhc130x0AMtYvZlfr/US6DjjmqQVj8xrKpA5D8RMgECzW C0jM+jDyeE57r2T29zX38gUrFWUjWV4QWimCoQlIBEWHBxxhfZcm7mSQwhf9pCjNTPaM j6HxJl8WlwGC+OlGVxnvKqKNZ2ddZ83MI1nZYqsnCrMvF1gUYJfECcMqq8l5iJlFrra6 PLDg== X-Gm-Message-State: AKS2vOyAxWGmQ/Kr1QO9h9d1ZxOycX2+TBvHncLvbjILxR3NWiN6clPW v+Xf6vDyVnEBk2F/ X-Received: by 10.107.63.139 with SMTP id m133mr27461593ioa.87.1497950440073; Tue, 20 Jun 2017 02:20:40 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id g67sm7196385iof.9.2017.06.20.02.20.37 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 20 Jun 2017 02:20:38 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 02/25] Adjust the order of 32bit-linux.xml and 32bit-sse.xml in i386/i386-linux.xml References: <1497256916-4958-1-git-send-email-yao.qi@linaro.org> <1497256916-4958-3-git-send-email-yao.qi@linaro.org> <9a60c2a9-09ef-c21a-db18-385105d986a1@redhat.com> <2469fcc8da14028094caf53330145210@polymtl.ca> <7872d3fa-7131-d84c-483d-05eca415ca63@redhat.com> Date: Tue, 20 Jun 2017 10:20:33 +0100 In-Reply-To: <7872d3fa-7131-d84c-483d-05eca415ca63@redhat.com> (Pedro Alves's message of "Mon, 19 Jun 2017 22:56:44 +0100") Message-ID: <86efuf582m.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Pedro Alves writes: This patch doesn't change the registers layout in gdbserver, because gdb/regformats/i386/i386-linux.dat isn't affected by this patch. It determines the register layout for i386-linux, in which "orig_eax" is already put the end of list, thanks to sort-regs.xsl. This patch only changes the order of iterating features and registers in GDB, however, the order doesn't matter. > It may be easy to check against gdbserver. You'd need to hack it to > disable the x86 xml tdesc support, which is a relatively > recent addition. [It took a while for the x86 port to support xml > tdescs]. The xmlRegisters= qSupported feature had to invented to > keep backward compatibility back then. > > E.g., hack gdb's remote.c:register_remote_support_xml, or > gdbserver's linux-x86-low.c:x86_linux_process_qsupported. > If, with x86 XML support disabled, before vs after patch the > layout of GDB's g/G packet buffer changes, then you have > a back compatibility break. I hacked remote.c:register_remote_support_xml like this, --- so GDB doesn't send qSupported:xmlRegisters=i386, and as a result, GDBserver doesn't reply GDB about the target description registers, Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Packet received: li386GNU/Linux The GDB's understanding to g/G packet layout is not changed, verified by "maintenance print remote-registers", (gdb) maintenance print remote-registers Name Nr Rel Offset Size Type Rmt Nr g/G Offset eax 0 0 0 4 int32_t 0 0 ecx 1 1 4 4 int32_t 1 4 edx 2 2 8 4 int32_t 2 8 ebx 3 3 12 4 int32_t 3 12 esp 4 4 16 4 *1 4 16 ebp 5 5 20 4 *1 5 20 esi 6 6 24 4 int32_t 6 24 edi 7 7 28 4 int32_t 7 28 eip 8 8 32 4 *1 8 32 eflags 9 9 36 4 i386_eflags 9 36 cs 10 10 40 4 int32_t 10 40 ss 11 11 44 4 int32_t 11 44 ds 12 12 48 4 int32_t 12 48 es 13 13 52 4 int32_t 13 52 fs 14 14 56 4 int32_t 14 56 gs 15 15 60 4 int32_t 15 60 st0 16 16 64 10 _i387_ext 16 64 st1 17 17 74 10 _i387_ext 17 74 st2 18 18 84 10 _i387_ext 18 84 st3 19 19 94 10 _i387_ext 19 94 st4 20 20 104 10 _i387_ext 20 104 st5 21 21 114 10 _i387_ext 21 114 st6 22 22 124 10 _i387_ext 22 124 st7 23 23 134 10 _i387_ext 23 134 fctrl 24 24 144 4 long 24 144 fstat 25 25 148 4 long 25 148 ftag 26 26 152 4 long 26 152 fiseg 27 27 156 4 long 27 156 fioff 28 28 160 4 long 28 160 foseg 29 29 164 4 long 29 164 fooff 30 30 168 4 long 30 168 fop 31 31 172 4 long 31 172 xmm0 32 32 176 16 vec128 32 176 xmm1 33 33 192 16 vec128 33 192 xmm2 34 34 208 16 vec128 34 208 xmm3 35 35 224 16 vec128 35 224 xmm4 36 36 240 16 vec128 36 240 xmm5 37 37 256 16 vec128 37 256 xmm6 38 38 272 16 vec128 38 272 xmm7 39 39 288 16 vec128 39 288 mxcsr 40 40 304 4 i386_mxcsr 40 304 '' 41 41 308 0 int0_t '' 42 42 308 0 int0_t '' 43 43 308 0 int0_t '' 44 44 308 0 int0_t '' 45 45 308 0 int0_t '' 46 46 308 0 int0_t '' 47 47 308 0 int0_t '' 48 48 308 0 int0_t '' 49 49 308 0 int0_t '' 50 50 308 0 int0_t '' 51 51 308 0 int0_t '' 52 52 308 0 int0_t '' 53 53 308 0 int0_t '' 54 54 308 0 int0_t '' 55 55 308 0 int0_t '' 56 56 308 0 int0_t '' 57 57 308 0 int0_t '' 58 58 308 0 int0_t '' 59 59 308 0 int0_t '' 60 60 308 0 int0_t '' 61 61 308 0 int0_t '' 62 62 308 0 int0_t '' 63 63 308 0 int0_t '' 64 64 308 0 int0_t '' 65 65 308 0 int0_t '' 66 66 308 0 int0_t '' 67 67 308 0 int0_t '' 68 68 308 0 int0_t '' 69 69 308 0 int0_t '' 70 70 308 0 int0_t '' 71 71 308 0 int0_t orig_eax 72 72 308 4 long 41 308 al 73 0 312 1 int8_t cl 74 1 313 1 int8_t dl 75 2 314 1 int8_t bl 76 3 315 1 int8_t ah 77 4 316 1 int8_t ch 78 5 317 1 int8_t dh 79 6 318 1 int8_t bh 80 7 319 1 int8_t ax 81 8 320 2 int16_t cx 82 9 322 2 int16_t dx 83 10 324 2 int16_t bx 84 11 326 2 int16_t '' 85 12 328 2 int16_t bp 86 13 330 2 int16_t si 87 14 332 2 int16_t di 88 15 334 2 int16_t mm0 89 16 336 8 _vec64i mm1 90 17 344 8 _vec64i mm2 91 18 352 8 _vec64i mm3 92 19 360 8 _vec64i mm4 93 20 368 8 _vec64i mm5 94 21 376 8 _vec64i mm6 95 22 384 8 _vec64i mm7 96 23 392 8 _vec64i however, I can't verify that GDBserver's understanding to g/G packet layout is not changed, unless we write a unit test, but as I analyzed above, the layout in GDBserver side doesn't change. --- a/gdb/remote.c +++ b/gdb/remote.c @@ -4711,6 +4711,7 @@ void register_remote_support_xml (const char *xml) { #if defined(HAVE_LIBEXPAT) +#if 0 if (remote_support_xml == NULL) remote_support_xml = concat ("xmlRegisters=", xml, (char *) NULL); else @@ -4735,6 +4736,7 @@ register_remote_support_xml (const char *xml) (char *) NULL); } #endif +#endif } static char *