From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31278 invoked by alias); 23 Oct 2014 05:43:34 -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 31268 invoked by uid 89); 23 Oct 2014 05:43:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qc0-f182.google.com Received: from mail-qc0-f182.google.com (HELO mail-qc0-f182.google.com) (209.85.216.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 23 Oct 2014 05:43:32 +0000 Received: by mail-qc0-f182.google.com with SMTP id i17so239221qcy.13 for ; Wed, 22 Oct 2014 22:43:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xICQI1FmuFqKJPNYcHN79fbsa0D+l0PJyGIMz5rf1h0=; b=i2Q6y4+2LBFBcCWwnU9Lf/3NtvF6YBsxuRnkhU9DHK2v5hfPfXMWn5kZCDUoNEv8MS 7AihEVXrSHZGdtYxIxW0Ip+jmHq9GQ/x7bzbwM8fLVIyUzfi8w44K+ryvdFBwyNJY3/e Z3V1kiMuCoeKnK5PUpYMOSVLMnRA40nlfpQ4IWUbcxS41u5b2pPoOYQzPuQPfIVz4MXJ WJrf2xnnjTXI55ADkZNhs681QO9nQYPhXsMD0DhKUTfQdmcx8txBTESPhgqQCdlxhXp6 lrModZZVelHg8qHshWZyzfTNk8R6pEyYOibmnRiXRNQvkjsOxwr48qI2kfaNgRniPonb UX6g== X-Gm-Message-State: ALoCoQm1ITASGQUDjt2zOpl9YYuhFfKUAMU3wzfT2LmAga+npvfh7xtsjOBcT2mj8cjzbrBpoIFh MIME-Version: 1.0 X-Received: by 10.140.38.8 with SMTP id s8mr4212072qgs.8.1414043009826; Wed, 22 Oct 2014 22:43:29 -0700 (PDT) Received: by 10.229.93.203 with HTTP; Wed, 22 Oct 2014 22:43:29 -0700 (PDT) In-Reply-To: <87tx2vh3rz.fsf@codesourcery.com> 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> <87tx2vh3rz.fsf@codesourcery.com> Date: Thu, 23 Oct 2014 05:43:00 -0000 Message-ID: Subject: Re: [PATCH 4/5] ARM: read_pieced_value do big endian processing only in case of valid gdb_regnum From: Victor Kamensky To: Yao Qi Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-10/txt/msg00599.txt.bz2 Hi Yao, I've posted updated V3 version only for this patch. I've modified commit message to include more details as you suggested. And I moved reg_offset var to more specific blocks as you noted. Please take a look. Would you like me to repost the whole series again (all 4 patches) or it would be OK just like this? Also it came up on binutils@ patch discussion with Alan - I do not have git commit permission. Is it my correct expectation once folks are OK with the patches, you or some other gdb maintainer will commit those? Thanks, Victor On 22 October 2014 20:18, Yao Qi wrote: > 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/testsu= ite/gdb.base/store.c, line 117. >> (gdb) run >> Starting program: /wd1/gdb/20140930/build-v7le/gdb/testsuite/gdb.base/st= ore >> >> Temporary breakpoint 1, wack_double (u=3D >> ../../binutils-gdb/gdb/regcache.c:177: internal-error: register_size: As= sertion `regnum >=3D 0 && regnum < (gdbarch_num_regs (gdbarch) + gdbarch_nu= m_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 >> <77a> DW_AT_name : (indirect string, offset: 0x3c9): wack_d= ouble >> <77e> DW_AT_decl_file : 1 >> <77f> DW_AT_decl_line : 115 >> <780> DW_AT_prototyped : 1 >> <780> DW_AT_type : <0x57c> >> <784> DW_AT_low_pc : 0x10758 >> <788> DW_AT_high_pc : 0x40 >> <78c> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_fram= e_cfa) >> <78e> DW_AT_GNU_all_tail_call_sites: 1 >> <78e> DW_AT_sibling : <0x7d7> >> <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_r= eg29 (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 >> <7a5> DW_AT_decl_file : 1 >> <7a6> DW_AT_decl_line : 115 >> <7a7> DW_AT_type : <0x57c> >> <7ab> DW_AT_location : 6 byte block: 6f 93 4 6e 93 4 (DW_OP_r= eg31 (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 >> <7b5> DW_AT_decl_file : 1 >> <7b6> DW_AT_decl_line : 117 >> <7b7> DW_AT_type : <0x57c> >> <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 >> <7c7> DW_AT_decl_file : 1 >> <7c8> DW_AT_decl_line : 117 >> <7c9> DW_AT_type : <0x57c> >> <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. > > -- > Yao (=E9=BD=90=E5=B0=A7)