From: Victor Kamensky <victor.kamensky@linaro.org>
To: Yao Qi <yao@codesourcery.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH 4/5] ARM: read_pieced_value do big endian processing only in case of valid gdb_regnum
Date: Thu, 23 Oct 2014 05:43:00 -0000 [thread overview]
Message-ID: <CAA3XUr2U5jeRZOi3o9+gr-Fk+J6oRM=Moxf8EfgX4Rv7tDvHJQ@mail.gmail.com> (raw)
In-Reply-To: <87tx2vh3rz.fsf@codesourcery.com>
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 <yao@codesourcery.com> wrote:
> Victor Kamensky <victor.kamensky@linaro.org> 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/testsuite/gdb.base/store.c, line 117.
>> (gdb) run
>> Starting program: /wd1/gdb/20140930/build-v7le/gdb/testsuite/gdb.base/store
>>
>> Temporary breakpoint 1, wack_double (u=
>> ../../binutils-gdb/gdb/regcache.c:177: internal-error: register_size: Assertion `regnum >= 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
>> =======
>>
>>
>> <1><779>: Abbrev Number: 12 (DW_TAG_subprogram)
>> <77a> DW_AT_external : 1
>> <77a> DW_AT_name : (indirect string, offset: 0x3c9): wack_double
>> <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_frame_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_reg29 (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_reg31 (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
>> ==========================================
>
> We don't need to copy the full stack back trace here.
>
> --
> Yao (齐尧)
next prev parent reply other threads:[~2014-10-23 5:43 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 0:57 [PATCH 0/5] arm: set of big endian related fixes for armeb (v7) Victor Kamensky
2014-10-21 0:57 ` [PATCH 1/5] ARM: plt_size functions need to read instructions in right byte order Victor Kamensky
2014-10-21 0:57 ` [PATCH 3/5] ARM: arm_breakpoint should be little endian form in case for arm BE8 Victor Kamensky
2014-10-21 8:13 ` Yao Qi
2014-10-21 0:57 ` [PATCH 2/5] ARM: extract_arm_insn function need to read instrs correctly in be8 case Victor Kamensky
2014-10-21 7:58 ` Yao Qi
2014-10-21 8:04 ` Yao Qi
2014-10-21 14:45 ` Victor Kamensky
2014-10-24 12:20 ` gdb/CONTRIBUTE Pedro Alves
2014-10-24 17:36 ` gdb/CONTRIBUTE Victor Kamensky
2014-10-21 0:57 ` [PATCH 5/5] ARM: asm-source.exp link options in case of armv7b target Victor Kamensky
2014-10-24 6:10 ` Yao Qi
2014-10-24 6:35 ` Victor Kamensky
2014-10-24 6:38 ` Andrew Pinski
2014-10-24 8:57 ` Yao Qi
2014-10-24 17:11 ` Victor Kamensky
2014-10-21 0:57 ` [PATCH 4/5] ARM: read_pieced_value do big endian processing only in case of valid gdb_regnum Victor Kamensky
2014-10-22 9:31 ` Yao Qi
2014-10-22 15:27 ` Victor Kamensky
2014-10-23 3:22 ` Yao Qi
2014-10-23 5:43 ` Victor Kamensky [this message]
2014-10-23 6:24 ` Yao Qi
2014-10-21 1:12 ` [PATCH 0/5] arm: set of big endian related fixes for armeb (v7) Andrew Pinski
2014-10-21 5:22 ` Victor Kamensky
2014-10-21 7:39 ` Yao Qi
2014-10-22 5:39 ` Victor Kamensky
2014-10-22 9:36 ` Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA3XUr2U5jeRZOi3o9+gr-Fk+J6oRM=Moxf8EfgX4Rv7tDvHJQ@mail.gmail.com' \
--to=victor.kamensky@linaro.org \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox