gdb and binutils branch master updated. ca45ab26f53023cab527eae940de86af4d03aa47

[kamensky at sourceware dot org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  ca45ab26f53023cab527eae940de86af4d03aa47 (commit)
       via  dcd4a3a4e7fc3912194d1346d2dfc6252f70b456 (commit)
       via  2959fed98cf1b1fd32516194619a5edbdf6a41a3 (commit)
      from  6ce8c98020188a7585c24db289191c5c10371e58 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ca45ab26f53023cab527eae940de86af4d03aa47

commit ca45ab26f53023cab527eae940de86af4d03aa47
Author: Victor Kamensky <victor.kamensky@linaro.org>
Date:   Sun Nov 2 13:28:35 2014 -0800

    read_pieced_value do big endian processing only in case of valid gdb_regnum
    
    During armv7b testing gdb.base/store.exp test was failling with
    'GDB internal error' with the following message:
    
    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.
    
    It turns out that compiler generated DWARF with non-existent
    register numbers. The compiler issue is present in both little endian
    (armv7) and big endian (armv7b) (it is separate issue). Here is
    example for one of formal parameters of wack_double function:
    
     <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)
    
    In both big and little endian cases gdbarch_dwarf2_reg_to_regnum
    returns -1 which is stored into gdb_regnum. But it causes severe
    problem only in big endian case because in read_pieced_value and
    write_pieced_value functions BFD_ENDIAN_BIG related processing
    happen regardless of gdb_regnum value, for example register_size
    function is called and in case of gdb_regnum=-1, it cause
    'GDB internal error' and crash.
    
    Solution is to move BFD_ENDIAN_BIG related processing under
    (gdb_regnum != -1) branch of processing.
    
    gdb/ChangeLog:
    
    2014-11-02  Victor Kamensky  <victor.kamensky@linaro.org>
    
    	* dwarf2loc.c (read_pieced_value): Do big endian
    	processing only if gdb_regnum is not -1.
    	(write_pieced_value): Ditto.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dcd4a3a4e7fc3912194d1346d2dfc6252f70b456

commit dcd4a3a4e7fc3912194d1346d2dfc6252f70b456
Author: Victor Kamensky <victor.kamensky@linaro.org>
Date:   Sun Nov 2 13:28:35 2014 -0800

    ARM: arm_breakpoint should be little endian form in case for arm BE8
    
    tdep->arm_breakpoint, tdep->thumb_breakpoint, tdep->thumb2_breakpoint
    should be set le_ variants in case of arm BE8 code. Those instruciton
    sequences are writen to target with simple write_memory, without
    regarding gdbarch_byte_order_for_code. But in BE8 case even data
    memory is in big endian form, instructions are still in little endian
    form.
    
    Because of this issue there are many issues while running gdb test
    case in armv7b mode. For example gdb.arch/arm-disp-step.exp test fails
    because it gets SIGILL when displaced instrucion sequence reaches
    break instruction, which is in wrong byte order.
    
    Solution is to set tdep->xxx_breakpoint sequences in BE8 case (i.e
    when gdbarch_byte_order_for_code is BFD_ENDIAN_BIG.
    
    gdb/ChangeLog:
    
    2014-11-02  Victor Kamensky  <victor.kamensky@linaro.org>
    
    	* arm-linux-tdep.c (arm_linux_init_abi): Use
    	info.byte_order_for_code to choose endianity of breakpoint
    	instructions snippets.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2959fed98cf1b1fd32516194619a5edbdf6a41a3

commit 2959fed98cf1b1fd32516194619a5edbdf6a41a3
Author: Victor Kamensky <victor.kamensky@linaro.org>
Date:   Sun Nov 2 13:28:35 2014 -0800

    ARM: extract_arm_insn function need to read instrs correctly in be8 case
    
    extract_arm_insn function needs to read instructions in
    gdbarch_byte_order_for_code byte order, because in case armv7b,
    even data is big endian, instructions are still little endian.
    Currently function uses gdbarch_byte_order which would be
    big endian in armv7b case.
    
    Because of this issue pretty much all gdb.reverse/ tests are
    failing with 'Process record does not support instruction' message.
    
    Fix is to change gdbarch_byte_order to gdbarch_byte_order_for_code,
    when passed to extract_unsigned_integer that reads instruction.
    
    gdb/ChangeLog:
    
    2014-11-02  Victor Kamensky  <victor.kamensky@linaro.org>
    
    	* arm-tdep.c (extract_arm_insn): Use
    	gdbarch_byte_order_for_code to read arm instruction.

-----------------------------------------------------------------------

Summary of changes:
 gdb/arm-linux-tdep.c |    2 +-
 gdb/arm-tdep.c       |    2 +-
 gdb/dwarf2loc.c      |   37 ++++++++++++++++++++-----------------
 3 files changed, 22 insertions(+), 19 deletions(-)


hooks/post-receive
-- 
gdb and binutils