Use 16-bit integer type for rl78 register pairs.

This patch changes rl78-tdep.c so that a 16-bit type is used for
register pairs instead of a pointer type as was previously the case.
This will cause these register pairs to be displayed as integers
instead of as a data address with a 0xf0000 ORed in.

E.g. registers ax, bc, de, and hl might now be displayed like this:

    (gdb) info registers ax bc de hl
    ax             0x6      6
    bc             0x0      0
    de             0x10c3   4291
    hl             0x108d   423

Whereas, before, they were displayed as follows:

    (gdb) info registers ax bc de hl
    ax             0xf0006  0xf0006
    bc             0xf0000  0xf0000
    de             0xf10c3  0xf10c3
    hl             0xf108d  0xf108d

These pairs are 16 bit quantities and should be displayed as such.
This change also affects the way that the banked register pairs are
displayed.  Within GDB, the banked register pairs are named bank0_rp0,
bank0_rp1, .., bank3_rp2, bank3_rp3.

However, these register pairs need to be used as addresses in DWARF
expressions.  I have added 16 pseudo registers corresponding to banked
register pairs.  These new pseudo registers are all hidden from the
user and have a pointer type.  Values from these registers are
intended to be used in DWARF expressions.  Therefore,
rl78_dwarf_reg_to_regnum() has been adjusted to return these new
pseudo register numbers.

I had a much simpler patch which only changed the types, but it showed
a number of regressions due to integer values from the banked register
pairs being used as part of an address expression.  This current patch
shows no regressions and now displays values of register pairs
correctly.

	* rl78-tdep.c ( RL78_BANK0_RP0_PTR_REGNUM, RL78_BANK0_RP1_PTR_REGNUM)
	(RL78_BANK0_RP2_PTR_REGNUM, RL78_BANK0_RP3_PTR_REGNUM)
	(RL78_BANK1_RP0_PTR_REGNUM, RL78_BANK1_RP1_PTR_REGNUM)
	(RL78_BANK1_RP2_PTR_REGNUM, RL78_BANK1_RP3_PTR_REGNUM)
	(RL78_BANK2_RP0_PTR_REGNUM, RL78_BANK2_RP1_PTR_REGNUM)
	(RL78_BANK2_RP2_PTR_REGNUM, RL78_BANK2_RP3_PTR_REGNUM)
	(RL78_BANK3_RP0_PTR_REGNUM, RL78_BANK3_RP1_PTR_REGNUM)
	(RL78_BANK3_RP2_PTR_REGNUM, RL78_BANK3_RP3_PTR_REGNUM):
	New constants.
	(rl78_register_type): Use a data pointer type for SP and
	new pseudo registers mentioned above.  Use a 16 bit integer
	type for all other register pairs.
	(rl78_register_name, rl78_g10_register_name): Update for
	new pseudo registers.
	(rl78_pseudo_register_read): Likewise.
	(rl78_pseudo_register_write): Likewise.
	(rl78_dwarf_reg_to_regnum): Return register numbers representing
	to the newly added pseudo registers.
2014-02-25  Hui Zhu  <hui@codesourcery.com>

	* target.h (target_ops): Fix TARGET_DEFAULT_RETURN of
	to_traceframe_info.
Fix a format issue of ChangeLog.
Adjust ia64_linux_xfer_partial following to_xfer_partial API change.

ia64-linux-nat.c no longer compiles because ia64_linux_xfer_partial
no longer matches the to_xfer_partial prototype.  This patch fixes
the problem by adjusting it accordingly.

gdb/ChangeLog:

        * ia64-linux-nat.c (ia64_linux_xfer_partial): Add function
        documentation.  Adjust prototype to match the target_ops
        to_xfer_partial method.  Adjust implementation accordingly.
Remove bogus vcvtps2ph variant.

We currently support version of vcvtps2ph with sae and only 1 register operand.
This version is encoded as if missing operand was equal to ymm0.
I didn't found any references to this variant in
http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf
This patch removes it.

opcodes/

        * i386-opc.tbl: Remove wrong variant of vcvtps2ph
        * i386-tbl.h: Regenerate.
Fix dw2-icycle.exp -fsanitize=address GDB crash.

binutils readelf -wi:
 <4><a2>: Abbrev Number: 26 (DW_TAG_inlined_subroutine)
    <a3>   DW_AT_abstract_origin: <0x5a>
    <a7>   DW_AT_low_pc      : 0x400590
    <ab>   DW_AT_high_pc     : 0x4
    <af>   DW_AT_call_file   : 1
    <b0>   DW_AT_call_line   : 20
    <b1>   DW_AT_sibling     : <0xb8>
 <2><b8>: Abbrev Number: 35 (DW_TAG_inlined_subroutine)
    <b9>   DW_AT_abstract_origin: <0x5a>
    <bd>   DW_AT_low_pc      : 0x400590
    <c1>   DW_AT_high_pc     : 0x4
    <c5>   DW_AT_call_file   : 1
    <c6>   DW_AT_call_line   : 29

<b1> DW_AT_sibling points to the next DIE - but that DIE is 2 levels
upwards - definitely not a sibling.  This confuses GDB up to a crash:

==32143== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6024000198ac at pc 0xb4d104 bp 0x7fff63e96e70 sp
0x7fff63e96e60
READ of size 1 at 0x6024000198ac thread T0
    #0 0xb4d103 in read_unsigned_leb128 (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb4d103)
    #1 0xb15f3c in peek_die_abbrev (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb15f3c)
    #2 0xb46185 in load_partial_dies (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb46185)
    #3 0xb103fb in process_psymtab_comp_unit_reader (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb103fb)
    #4 0xb0d2a9 in init_cutu_and_read_dies (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb0d2a9)
    #5 0xb1115f in process_psymtab_comp_unit (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb1115f)
    #6 0xb1235f in dwarf2_build_psymtabs_hard (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb1235f)
    #7 0xb05536 in dwarf2_build_psymtabs (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xb05536)
    #8 0x86d5a5 in read_psyms (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x86d5a5)
    #9 0x9b1c37 in require_partial_symbols (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x9b1c37)
    #10 0x9bf2d0 in read_symbols (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x9bf2d0)
    #11 0x9c014c in syms_from_objfile_1 (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x9c014c)

gdb/testsuite/
2014-02-25  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix dw2-icycle.exp -fsanitize=address GDB crash.
	* gdb.dwarf2/dw2-icycle.S: Remove all DW_AT_sibling.

Message-ID: <20140224201011.GA28926@host2.jankratochvil.net>
PR gdb/16626

Fix auto-load 7.7 regression,
the regression affects any loading from /usr/share/gdb/auto-load .

5b2bf9471f1499bee578fcd60c05afe85794e280 is the first bad commit
commit 5b2bf9471f1499bee578fcd60c05afe85794e280
Author: Doug Evans <xdje42@gmail.com>
Date:   Fri Nov 29 21:29:26 2013 -0800
    Move .debug_gdb_script processing to auto-load.c.
    Simplify handling of auto-loaded objfile scripts.

Fedora 20 x86_64
$ gdb -q /usr/lib64/libgobject-2.0.so
Reading symbols from /usr/lib64/libglib-2.0.so.0.3800.2...Reading symbols from
/usr/lib/debug/usr/lib64/libglib-2.0.so.0.3800.2.debug...done.
done.
(gdb) _

Fedora Rawhide x86_64
$ gdb -q /usr/lib64/libgobject-2.0.so
Reading symbols from /usr/lib64/libglib-2.0.so...Reading symbols from
/usr/lib/debug/usr/lib64/libglib-2.0.so.0.3990.0.debug...done.
done.
warning: File "/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py" auto-loading has been declined by your `auto-load safe-path'
set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
To enable execution of this file add
        add-auto-load-safe-path /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
line to your configuration file "/home/jkratoch/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/home/jkratoch/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
(gdb) _

That is it tries to load "forbidden"
	/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
but it should load instead
	/usr/share/gdb/auto-load/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py*
Although that is also not exactly this way, there does not exist any
	/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
despite regressed GDB says so.

gdb/
2014-02-24  Jan Kratochvil  <jan.kratochvil@redhat.com>

	PR gdb/16626
	* auto-load.c (auto_load_objfile_script_1): Change filename to
	debugfile.

gdb/testsuite/
2014-02-24  Jan Kratochvil  <jan.kratochvil@redhat.com>

	PR gdb/16626
	* gdb.base/auto-load-script: New file.
	* gdb.base/auto-load.c: New file.
	* gdb.base/auto-load.exp: New file.

Message-ID: <20140223212400.GA8831@host2.jankratochvil.net>
remove target_ignore

This removes target_ignore, which isn't used any more.

2014-02-25  Tom Tromey  <tromey@redhat.com>

	* target.h (target_ignore): Don't declare.
	* target.c (target_ignore): Remove.
PR gdb/16626

gdb/testsuite/
2014-02-25  Jan Kratochvil  <jan.kratochvil@redhat.com>

	PR gdb/16626
	* gdb.base/auto-load.exp: Fix out-of-srctree run.

Message-ID: <87k3cjt3jl.fsf@fleche.redhat.com>
daily update
Annotate comments for Doxygen.
Re-implement ia64-linux-nat.c::ia64_linux_xfer_partial

[description of this patch and ChangeLog entry by Joel Brobecker]
The recent implementation was questionable, and if it worked, it was
only by chance because the requested length is large enough that only
one read was sufficient.  Note that the implementation before that
also made that assumption, in the form of only handling
TARGET_OBJECT_UNWIND_TABLE xfer requests when offset was zero.

gdb/ChangeLog:

        * ia64-linux-nat.c (ia64_linux_xfer_partial): Reimplement
        handling of object == TARGET_OBJECT_UNWIND_TABLE.
Resolve PR ld/16569 by emitting (and comparing) unmangled names, unless
demangling has specifically been requested.
Multiple Ada task-specific breakpoints at the same address.

With the test changed as in the patch, against current mainline, we get:

 (gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint
 break break_me task 1
 Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
 (gdb) PASS: gdb.ada/tasks.exp: break break_me task 1
 break break_me task 3
 Note: breakpoint 2 also set at pc 0x4030b0.
 Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
 (gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
 continue
 Continuing.
 [Switching to Thread 0x7ffff7dc7700 (LWP 27133)]

 Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
 27	      null;
 (gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint
 info tasks
    ID       TID P-ID Pri State                  Name
     1    63b010       48 Waiting on RV with 3   main_task
     2    63bd80    1  48 Accept or Select Term  task_list(1)
 *   3    63f510    1  48 Accepting RV with 1    task_list(2)
     4    642ca0    1  48 Accept or Select Term  task_list(3)
 (gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint

The breakpoint that caused a stop is breakpoint 3, but GDB end up
reporting (and running breakpoint commands of) "Breakpoint 2" instead.

The issue is that the bpstat_check_breakpoint_conditions logic of
"wrong thread" is missing the "wrong task" check.  This is usually
harmless, because the thread hop code in infrun.c code that handles
wrong-task-hitting-breakpoint does check for task-specific breakpoints
(within breakpoint_thread_match):

      /* Check if a regular breakpoint has been hit before checking
         for a potential single step breakpoint.  Otherwise, GDB will
         not see this breakpoint hit when stepping onto breakpoints.  */
      if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
	{
	  if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
	    thread_hop_needed = 1;
	}

IOW, usually, when one only has a task specific breakpoint at a given
address, things work correctly.  Put another task-specific or
non-task-specific breakpoint there, and things break.

A patch that eliminates the special thread hop code in infrun.c is
what exposed this, as after that GDB solely relies on
bpstat_check_breakpoint_conditions to know whether the right or wrong
task hit a breakpoint.  IOW, given the latent bug, Ada task-specific
breakpoints become non-task-specific, and that is caught by the
testsuite, as:

 break break_me task 3
 Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
 (gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
 continue
 Continuing.
 [Switching to Thread 0x7ffff7fcb700 (LWP 17122)]

 Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
 27	      null;
 (gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint
 info tasks
    ID       TID P-ID Pri State                  Name
     1    63b010       48 Waiting on RV with 2   main_task
 *   2    63bd80    1  48 Accepting RV with 1    task_list(1)
     3    63f510    1  48 Accept or Select Term  task_list(2)
     4    642ca0    1  48 Accept or Select Term  task_list(3)
 (gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint

It was after seeing this that I thought of how to expose the bug with
current mainline.

Tested on x86_64 Fedora 17.

gdb/
2014-02-26  Pedro Alves  <palves@redhat.com>

	* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
	task-specific breakpoints.

gdb/testsuite/
2014-02-26  Pedro Alves  <palves@redhat.com>

	* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
	that won't ever trigger.  Make sure that GDB reports the correct
	breakpoint that caused the stop.
DWARF: Add array DW_AT_bit_stride and DW_AT_byte_stride support

Consider the following declarations in Ada...

   type Item is range -32 .. 31;
   for Item'Size use 6;

   type Table is array (Natural range 0 .. 4) of Item;
   pragma Pack (Table);

... which declare a packed array whose elements are 6 bits long.
The debugger currently does not notice that the array is packed,
and thus prints values of this type incorrectly. This can be seen
in the "ptype" output:

    (gdb) ptype table
    type = array (0 .. 4) of foo.item

Normally, the debugger should print:

    (gdb) ptype table
    type = array (0 .. 4) of foo.item <packed: 6-bit elements>

The debugging information for this array looks like this:

        .uleb128 0xf    # (DIE (0x15c) DW_TAG_array_type)
        .long   .LASF9  # DW_AT_name: "pck__table"
        .byte   0x6     # DW_AT_bit_stride
        .long   0x1a9   # DW_AT_type
        .uleb128 0x10   # (DIE (0x16a) DW_TAG_subrange_type)
        .long   0x3b    # DW_AT_type
        .byte   0       # DW_AT_lower_bound
        .byte   0x4     # DW_AT_upper_bound
        .byte   0       # end of children of DIE 0x15c

The interesting part is the DW_AT_bit_stride attribute, which tells
the size of the array elements is 6 bits, rather than the normal
element type's size.

This patch adds support for this attribute by first creating
gdbtypes.c::create_array_type_with_stride, which is an enhanced
version of create_array_type taking an extra parameter as the stride.
The old create_array_type can then be re-implemented very simply
by calling the new create_array_type_with_stride.

We can then use this new function from dwarf2read, to create
arrays with or without stride.

gdb/ChangeLog:

        * gdbtypes.h (create_array_type_with_stride): Add declaration.
        * gdbtypes.c (create_array_type_with_stride): New function,
        renaming create_array_type, but with an added parameter
        called "bit_stride".
        (create_array_type): Re-implement using
        create_array_type_with_stride.
        * dwarf2read.c (read_array_type): Add support for DW_AT_byte_stride
        and DW_AT_bit_stride attributes.

gdb/testsuite/ChangeLog:

        * gdb.dwarf2/arr-stride.c: New file.
        * gdb.dwarf2/arr-stride.exp: New file.

The test, relying purely on generating an assembly file, only
verifies the type description of our array. But I was also
able to verify manually that the debugger print values of these
types correctly as well (which was not the case prior to this
patch).
remote-mips.c: Don't install a deprecated_xfer_memory method

This removes another yet instance of a deprecated_xfer_memory user.

Tested by building a --enable-targets=all gdb, on x86-64 Fedora 17.

gdb/
2014-02-26  Pedro Alves  <palves@redhat.com>

	* remote-mips.c (mips_xfer_memory): Adjust as to_xfer_partial
	helper.
	(mips_xfer_partial): New function.
	(_initialize_remote_mips): Don't install a deprecated_xfer_memory
	hook.  Install a to_xfer_partial hook.
remote-m32r-sdi.c: Don't install a deprecated_xfer_memory method

This removes yet another instance of a deprecated_xfer_memory user.

Tested by building a --enable-targets=all gdb, on x86-64 Fedora 17.

gdb/
2014-02-26  Pedro Alves  <palves@redhat.com>

	* remote-m32r-sdi.c (send_data): Constify 'buf' parameter.
	(m32r_xfer_memory): Adjust as a to_xfer_partial helper.
	(m32r_xfer_partial): New function.
	(init_m32r_ops): Don't install a deprecated_xfer_memory hook.
	Install a to_xfer_partial hook.
nto-procfs.c: Don't install a deprecated_xfer_memory method

This removes yet another instance of a deprecated_xfer_memory user.

Completely untested.

gdb/
2014-02-26  Pedro Alves  <palves@redhat.com>

	* nto-procfs.c (procfs_xfer_memory): Adjust interface as a
	to_xfer_partial helper.  Rewrite.
	(procfs_xfer_partial): New function.
	(init_procfs_ops): Don't install a deprecated_xfer_memory hook.
	Install a to_xfer_partial hook.
go32-nat.c: Don't install a deprecated_xfer_memory method

This removes yet another instance of a deprecated_xfer_memory user.

Unfortunately djgpp's write_child function takes a non-const buffer
pointer, while GDB's xfer_partial api passes a const pointer.  To be
const-correct, we need to copy that buffer to a non-const buffer, and
pass the copy to write_child.  This is actually what
target.c:default_xfer_partial itself does, when calling into the
ops->deprecated_xfer_memory hook.

Tested by cross-building djgpp gdb, on x86-64 Fedora 17.

gdb/
2014-02-26  Pedro Alves  <palves@redhat.com>

	* go32-nat.c (my_write_child): New function.
	(go32_xfer_memory): Rewrite as to_xfer_partial helper.
	(go32_xfer_partial): New function.
	(init_go32_ops): Don't install a deprecated_xfer_memory hook.
	Instead install a to_xfer_partial hook.
eliminate target_ops->deprecated_xfer_memory

As no target uses it anymore, it can finally go away.

After removing the deprecated_xfer_memory handling from
default_xfer_partial, we can delete the latter, because the only thing
it does is delegate to the target beneath unconditionally, which is
what the delegator installed by target-delegates.c will do for us if
no to_xfer_partial method is installed.

This was the last user of de_fault, so that goes away too.

Tested on x86_64 Fedora 17.

gdb/
2014-02-26  Pedro Alves  <palves@redhat.com>

	* target.c (complete_target_initialization): Don't install
	default_xfer_partial as to_xfer_partial hook.
	(nomemory): Delete.
	(update_current_target): Don't INHERIT nor de_fault
	deprecated_xfer_memory.  Delete de_fault macro.
	(default_xfer_partial, deprecated_debug_xfer_memory): Delete.
	(setup_target_debug): Don't install a deprecated_xfer_memory hook.
	* target.h (struct target_ops) <deprecated_xfer_memory>: Delete
	field.