From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32546 invoked by alias); 23 Oct 2014 03:22:51 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 32530 invoked by uid 89); 23 Oct 2014 03:22:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Oct 2014 03:22:48 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1Xh8z7-0000sz-4s from Yao_Qi@mentor.com ; Wed, 22 Oct 2014 20:22:45 -0700 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.181.6; Wed, 22 Oct 2014 20:22:44 -0700 From: Yao Qi To: Victor Kamensky CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH 4/5] ARM: read_pieced_value do big endian processing only in case of valid gdb_regnum References: <1413853021-4393-1-git-send-email-victor.kamensky@linaro.org> <1413853021-4393-5-git-send-email-victor.kamensky@linaro.org> <877fzsihdr.fsf@codesourcery.com> Date: Thu, 23 Oct 2014 03:22:00 -0000 In-Reply-To: (Victor Kamensky's message of "Wed, 22 Oct 2014 08:27:18 -0700") Message-ID: <87tx2vh3rz.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00595.txt.bz2 Victor Kamensky writes: > In both little endian and big endian cases compiler generate DW_OP_reg29- > DW_OP_reg31 something like this. > > <2><792>: Abbrev Number: 10 (DW_TAG_formal_parameter) > <793> DW_AT_name : u > <795> DW_AT_decl_file : 1 > <796> DW_AT_decl_line : 115 > <797> DW_AT_type : <0x57c> > <79b> DW_AT_location : 6 byte block: 6d 93 4 6c 93 4 > (DW_OP_reg29 (r29); DW_OP_piece: 4; DW_OP_reg28 (r28); DW_OP_piece: 4) > This is quite illustrative. > I strongly suspect that it is compiler error, but more accurately > it is hard to say, because I never saw a document where for given CPU > mapping from registers to DWARF reg numbers is defined. Have you > seen such document for example for ARM V7? In any case for this > test case Gdb believes that those register numbers are wrong. I.e we > can say for sure that gcc and gdb are disagrees. You need doc "DWARF for the ARM Architecture", which has a table about the mapping between dwarf reg numbers and processor registers. For the table, we can see that dwarf register 16 to 63 doesn't map to any processor registers. > > > (gdb) file /wd1/gdb/20140930/build-v7le/gdb/testsuite/gdb.base/store > Reading symbols from /wd1/gdb/20140930/build-v7le/gdb/testsuite/gdb.base/= store...done. > (gdb) tbreak wack_double > Temporary breakpoint 1 at 0x1076c: file ../../../binutils-gdb/gdb/testsui= te/gdb.base/store.c, line 117. > (gdb) run > Starting program: /wd1/gdb/20140930/build-v7le/gdb/testsuite/gdb.base/sto= re=20 > > Temporary breakpoint 1, wack_double (u=3D > ../../binutils-gdb/gdb/regcache.c:177: internal-error: register_size: Ass= ertion `regnum >=3D 0 && regnum < (gdbarch_num_regs (gdbarch) + gdbarch_num= _pseudo_regs (gdbarch))' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > This is quite useful too. > > BE Dump > =3D=3D=3D=3D=3D=3D=3D > > > <1><779>: Abbrev Number: 12 (DW_TAG_subprogram) > <77a> DW_AT_external : 1=20=20=20=20=20=20=20 > <77a> DW_AT_name : (indirect string, offset: 0x3c9): wack_do= uble=20=20=20 > <77e> DW_AT_decl_file : 1=20=20=20=20=20=20=20 > <77f> DW_AT_decl_line : 115=20=20=20=20=20 > <780> DW_AT_prototyped : 1=20=20=20=20=20=20=20 > <780> DW_AT_type : <0x57c>=20 > <784> DW_AT_low_pc : 0x10758=20 > <788> DW_AT_high_pc : 0x40=20=20=20=20 > <78c> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame= _cfa) > <78e> DW_AT_GNU_all_tail_call_sites: 1=20=20=20=20 > <78e> DW_AT_sibling : <0x7d7>=20 > <2><792>: Abbrev Number: 10 (DW_TAG_formal_parameter) > <793> DW_AT_name : u=20=20=20=20=20=20=20 > <795> DW_AT_decl_file : 1=20=20=20=20=20=20=20 > <796> DW_AT_decl_line : 115=20=20=20=20=20 > <797> DW_AT_type : <0x57c>=20 > <79b> DW_AT_location : 6 byte block: 6d 93 4 6c 93 4 (DW_OP_re= g29 (r29); DW_OP_piece: 4; DW_OP_reg28 (r28); DW_OP_piece: 4) > <2><7a2>: Abbrev Number: 10 (DW_TAG_formal_parameter) > <7a3> DW_AT_name : v=20=20=20=20=20=20=20 > <7a5> DW_AT_decl_file : 1=20=20=20=20=20=20=20 > <7a6> DW_AT_decl_line : 115=20=20=20=20=20 > <7a7> DW_AT_type : <0x57c>=20 > <7ab> DW_AT_location : 6 byte block: 6f 93 4 6e 93 4 (DW_OP_re= g31 (r31); DW_OP_piece: 4; DW_OP_reg30 (r30); DW_OP_piece: 4) > <2><7b2>: Abbrev Number: 13 (DW_TAG_variable) > <7b3> DW_AT_name : l=20=20=20=20=20=20=20 > <7b5> DW_AT_decl_file : 1=20=20=20=20=20=20=20 > <7b6> DW_AT_decl_line : 117=20=20=20=20=20 > <7b7> DW_AT_type : <0x57c>=20 > <7bb> DW_AT_location : 8 byte block: 90 21 93 4 90 20 93 4 (= DW_OP_regx: 33 (r33); DW_OP_piece: 4; DW_OP_regx: 32 (r32); DW_OP_piece: 4) > <2><7c4>: Abbrev Number: 13 (DW_TAG_variable) > <7c5> DW_AT_name : r=20=20=20=20=20=20=20 > <7c7> DW_AT_decl_file : 1=20=20=20=20=20=20=20 > <7c8> DW_AT_decl_line : 117=20=20=20=20=20 > <7c9> DW_AT_type : <0x57c>=20 > <7cd> DW_AT_location : 8 byte block: 90 23 93 4 90 22 93 4 (= DW_OP_regx: 35 (r35); DW_OP_piece: 4; DW_OP_regx: 34 (r34); DW_OP_piece: 4) > However, we don't need to copy the whole DIE here, instead, we can only copy one DW_TAG_formal_parameter, which is should be illustrative enough for the problem. > Backtrace when it failed to get reg number > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We don't need to copy the full stack back trace here. --=20 Yao (=E9=BD=90=E5=B0=A7)