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.
bsd-uthread.c: Don't install a to_xfer_partial method

Whatever the comment about deprecated_xfer_memory referred to,
deprecated_xfer_memory is gone now.  There's no need to install a
target method that just delegates, as that's what the default
delegator does already.

Tested by building an --enable-targets=all gdb on x86_64 Fedora 17.

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

	* bsd-uthread.c (bsd_uthread_xfer_partial): Delete function.
	(bsd_uthread_target): Don't install bsd_uthread_xfer_partial as
	to_xfer_partial method.