Automatic link generation by doxygen

Nowadays, we have one page on "GDB Types" generated by doxygen, but types
and macros referenced in doc are not linked to their definitions.  This
patch tweaks the comments a little to use doxygen syntax so that these
types and macros are linked their definitions.

Is it OK?

gdb:

2014-04-17  Yao Qi  <yao@codesourcery.com>

	* gdbtypes.h: Update comments to link to types and macros'
	definitions.
[testsuite] Set target-charset to ascii

Hi,
We find gdb.base/printcmds.exp fails a lot on windows host, like this,

 p ctable1[163]
 $204 = 163 '£'
 (gdb) FAIL: gdb.base/printcmds.exp: p ctable1[163]

however, on linux host,

 p ctable1[163]
 $205 = 163 '\243'
 (gdb) PASS: gdb.base/printcmds.exp: p ctable1[163]

The printing related code is in valprint.c:print_wchar,

  if (gdb_iswprint (w) && (!need_escape || (!gdb_iswdigit (w)
					    && w != LCST ('8')
					    && w != LCST ('9'))))
    {
      gdb_wchar_t wchar = w;

      if (w == gdb_btowc (quoter) || w == LCST ('\\'))
	obstack_grow_wstr (output, LCST ("\\"));
      obstack_grow (output, &wchar, sizeof (gdb_wchar_t));
    }
  else
   {
      // print W in hex or octal digits
   }

When I debug gdb on different hosts, I find
on windows host, gdb_iswprint (iswprint) returns true if 'w' is 163.
However, on linux host, iswprint returns false if 'w' is 163.  Looks
this difference is caused by the charset.  On Linux host,
the target-charset is ANSI_X3.4-1968, while on windows host, the
target-charset is CP1252.

We can see how target-charset affects the output.  On linux host,

 (gdb) set target-charset ASCII
 (gdb) p ctable1[163]
 $1 = 163 '\243'
 (gdb) set target-charset CP1252
 (gdb) p ctable1[163]
 $2 = 163 '£'

we can print the pound sign too, and it shows target-charset does
affect the output.

This patch is to set target-charset temporarily to ASCII for some
charset-sensitive tests.  Tested on arm-none-eabi and
powerpc-linux-gnu on mingw32 host.  More than one hundred fails are
fixed.

gdb/testsuite:

2014-04-17  Yao Qi  <yao@codesourcery.com>

	* lib/gdb.exp (with_target_charset): New proc.
	* gdb.base/printcmds.exp (test_print_all_chars): Wrap tests with
	with_target_charset.
	(test_print_strings): Likewise.
	(test_repeat_bytes): Likewise.
	* gdb.base/setvar.exp: Set target-charset to ASCII temporarily
	for some tests.
Fix LTO mismatched TLS reference

	PR 16846
	* elflink.c (_bfd_elf_merge_symbol): Ignore TLS mismatch when
	current bfd is a plugin.  Don't always set type_change_ok
	when old bfd is a plugin.
Drop prefix from unsupported source path.
Use address_from_register in dwarf2-frame.c:read_addr_from_reg

This patch fixes a problem that prevented use of the Dwarf unwinders on SPU,
because dwarf2-frame.c common code did not support the situation where the
stack and/or frame pointer is maintained in a *vector* register.  This is
because read_addr_from_reg is hard-coded to assume that such pointers can
be read from registers via a simple get_frame_register / unpack_pointer
operation.

Now, there *is* a routine address_from_register that calls into the
appropriate tdep routines to handle pointer values in "weird" registers
like on SPU, but it turns out I cannot simply change dwarf2-frame.c to
use address_from_register.  This is because address_from_register uses
value_from_register to create a (temporary) value, and that routine
at some point calls get_frame_id in order to set up that value's
VALUE_FRAME_ID entry.

However, the dwarf2-frame.c read_addr_from_reg routine will be called
during early unwinding (to unwind the frame's CFA), at which point the
frame's ID is not actually known yet!  This would cause an assert.

On the other hand, we may notice that VALUE_FRAME_ID is only needed in the
value returned by value_from_register if that value is later used as an
lvalue.  But this is obviously never done to the temporary value used in
address_from_register.  So, if we could change address_from_register to
not call value_from_register but instead accept constructing a value
that doesn't have VALUE_FRAME_ID set, things should be fine.

To do that, we can change the value_from_register callback to accept
a FRAME_ID instead of a FRAME; the only existing uses of the FRAME
argument were either to extract its frame ID, or its gdbarch.  (To
keep a way of getting at the latter, we also change the callback's
type from "f" to "m".)  Together with the required follow-on changes
in the existing value_from_register implementations (including the
default one), this seems to fix the problem.

As another minor interface cleanup, I've removed the explicit TYPE
argument from address_from_register.  This routine really always
uses a default pointer type, and in the new implementation it -to
some extent- relies on that fact, in that it will now no longer
handle types that require gdbarch_convert_register_p handling.

gdb:
2014-04-17  Ulrich Weigand  <uweigand@de.ibm.com>

	* gdbarch.sh (value_from_register): Make class "m" instead of "f".
	Replace FRAME argument with FRAME_ID.
	* gdbarch.c, gdbarch.h: Regenerate.
	* findvar.c (default_value_from_register): Add GDBARCH argument;
	replace FRAME by FRAME_ID.  No longer call get_frame_id.
	(value_from_register): Update call to gdbarch_value_from_register.
	* value.h (default_value_from_register): Update prototype.
	* s390-linux-tdep.c (s390_value_from_register): Update interface
	and call to default_value_from_register.
	* spu-tdep.c (spu_value_from_register): Likewise.

	* findvar.c (address_from_register): Remove TYPE argument.
	Do not call value_from_register; use gdbarch_value_from_register
	with null_frame_id instead.
	* value.h (address_from_register): Update prototype.
	* dwarf2-frame.c (read_addr_from_reg): Use address_from_register.
	* dwarf2loc.c (dwarf_expr_read_addr_from_reg): Update for
	address_from_register interface change.
Enable DWARF unwinders for SPU

This patch enables use of DWARF unwinders for the SPU target.

In addition to appending the DWARF unwinders, we also need to install
a spu_dwarf_reg_to_regnum that maps the raw stack pointer register to
the cooked version (to avoid mismatches with gdbarch_sp_regnum).

This also causes confusion with the AX collect handling, so we also
install ax_pseudo_register routines to handle the cooked SP.

gdb/
2014-04-17  Ulrich Weigand  <uweigand@de.ibm.com>

	* spu-tdep.c: Include "dwarf2-frame.h" and "ax.h".
	(spu_ax_pseudo_register_collect): New function.
	(spu_ax_pseudo_register_push_stack): Likewise.
	(spu_dwarf_reg_to_regnum): Likewise.
	(spu_gdbarch_init): Install them.  Append DWARF unwinders.
This patch causes local GOT entries addressed via a 16-bit index to
be placed towards the front of local GOT space, while entries addressed
via a 32-bit index are placed towards the rear.

Provided that there are fewer than ~16K local GOT entries addressed via
a 16-bit index in total, this should eliminate any relocation overflows
caused by such GOT entries being allocated beyond the addressable range.

bfd/
	* elfxx-mips.c (struct mips_got_info): Delete assigned_gotno
	field.  Add assigned_low_gotno and assigned_high_gotno fields.
	(mips_elf_create_local_got_entry): Update out-of-space condition.
	Set index of new GOT entry to assigned_low_gotno if required by
	the current relocation, else set it to assigned_high_gotno.
	(mips_elf_set_global_gotidx): Replace uses of assigned_gotno
	with assigned_low_gotno.
	(mips_elf_multi_got): Initialize assigned_low_gotno and
	assigned_high_gotno in secondary GOTs.  Use assigned_low_gotno
	in place of assigned_gotno when handling global GOT entries.
	(mips_elf_lay_out_got): Initialize assigned_low_gotno and
	assigned_high_gotno.
	(_bfd_mips_elf_finish_dynamic_sections): Account for a possible
	gap in the middle of local GOT space.

ld/testsuite/
	* ld-mips-elf/elf-rel-xgot-n32.d: Update for new GOT layout.
	* ld-mips-elf/elf-rel-xgot-n32-embed.d: Likewise.
	* ld-mips-elf/elf-rel-xgot-n64.d: Likewise.
	* ld-mips-elf/elf-rel-xgot-n64-embed.d: Likewise.
	* ld-mips-elf/elf-rel-xgot-n64-linux.d: Likewise.
Drop srcdir from untested source path.
daily update