tic6x-tdep: set default frame base

2014-02-12  Sanimir Agovic  <sanimir.agovic@intel.com>

	* tic6x-tdep.c (tic6x_gdbarch_init): Call frame_base_set_default.
nios2-tdep: remove unreferenced global nios2_stub_frame_base

2014-02-12  Sanimir Agovic  <sanimir.agovic@intel.com>

	* nios2-tdep.c (nios2_stub_frame_base): Remove global.
H8/300: Fix gdb<->sim register mapping.

Currently, printing the H8/300 ccr register when debugging with the
sim is broken:

 (gdb) target sim
 ...
 (gdb) load
 ...
 (gdb) start
 ...
 Breakpoint 1, foo (i=0x0 <foo>) at main.c:4
 4       {
 (gdb) info registers ccr
 Register 13 is not available

'13' is the ccr pseudo-register.  This pseudo-register provides an
8-bit view into the raw ccr register (regno=8).

The problem is that the H8/300 port does not define a
register_sim_regno gdbarch hook, and thus when fetching the raw
register off of the sim, we end up in legacy_register_sim_regno trying
to figure out the sim register number for the raw CCR register:

 int
 legacy_register_sim_regno (struct gdbarch *gdbarch, int regnum)
 {
   /* Only makes sense to supply raw registers.  */
   gdb_assert (regnum >= 0 && regnum < gdbarch_num_regs (gdbarch));
   /* NOTE: cagney/2002-05-13: The old code did it this way and it is
      suspected that some GDB/SIM combinations may rely on this
      behavour.  The default should be one2one_register_sim_regno
      (below).  */
   if (gdbarch_register_name (gdbarch, regnum) != NULL
       && gdbarch_register_name (gdbarch, regnum)[0] != '\0')
     return regnum;
   else
     return LEGACY_SIM_REGNO_IGNORE;
 }

Because the raw ccr register does not have a name (so that it is
hidden from the user), that returns LEGACY_SIM_REGNO_IGNORE.  That
means that we never actually read the value of the raw ccr register.

Before the <unavailable> support, this must have meant that ccr was
_always_ read as 0...  At least, I'm not seeing how this ever worked.

The fix for that is adding a gdbarch_register_sim_regno hook that maps
all raw registers.  Looking at sim/h8300/sim-main.h, I believe the
sim's register numbers are compatible with gdb's, so no actual
convertion is necessary.

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

	* h8300-tdep.c (h8300_register_sim_regno): New function.
	(h8300_gdbarch_init): Install h8300_register_sim_regno as
	gdbarch_register_sim_regno hook.
H8/300: Fix pseudo registers reads/writes.

'info registers ccr' corrupts memory.

Debugging gdb under Valgrind, we see:

 (gdb) info registers ccr
 ==23225== Invalid write of size 1
 ==23225==    at 0x4A0A308: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:881)
 ==23225==    by 0x52D334: regcache_raw_read (regcache.c:625)
 ==23225==    by 0x45E4D8: h8300_pseudo_register_read (h8300-tdep.c:1171)
 ==23225==    by 0x5B694B: gdbarch_pseudo_register_read (gdbarch.c:1926)
 ==23225==    by 0x52DADB: regcache_cooked_read (regcache.c:740)
 ==23225==    by 0x52DC10: regcache_cooked_read_value (regcache.c:765)
 ==23225==    by 0x68CA41: sentinel_frame_prev_register (sentinel-frame.c:52)
 ==23225==    by 0x6B80CB: frame_unwind_register_value (frame.c:1105)
 ==23225==    by 0x6B7C97: frame_register_unwind (frame.c:1010)
 ==23225==    by 0x6B7F73: frame_unwind_register (frame.c:1064)
 ==23225==    by 0x6B8359: frame_unwind_register_signed (frame.c:1162)
 ==23225==    by 0x6B8396: get_frame_register_signed (frame.c:1169)
 ==23225==  Address 0x4f7b031 is 0 bytes after a block of size 1 alloc'd
 ==23225==    at 0x4A06B0F: calloc (vg_replace_malloc.c:593)
 ==23225==    by 0x6EB754: xcalloc (common-utils.c:91)
 ==23225==    by 0x6EB793: xzalloc (common-utils.c:101)
 ==23225==    by 0x53A782: allocate_value_contents (value.c:854)
 ==23225==    by 0x53A7B4: allocate_value (value.c:864)
 ==23225==    by 0x52DBC8: regcache_cooked_read_value (regcache.c:757)
 ==23225==    by 0x68CA41: sentinel_frame_prev_register (sentinel-frame.c:52)
 ==23225==    by 0x6B80CB: frame_unwind_register_value (frame.c:1105)
 ==23225==    by 0x6B7C97: frame_register_unwind (frame.c:1010)
 ==23225==    by 0x6B7F73: frame_unwind_register (frame.c:1064)
 ==23225==    by 0x6B8359: frame_unwind_register_signed (frame.c:1162)
 ==23225==    by 0x6B8396: get_frame_register_signed (frame.c:1169)
 ==23225==
 ccr            0x00        0    I-0 UI-0 H-0 U-0 N-0 Z-0 V-0 C-0 u> u>= != >= >
 (gdb)

This bit:

 ==23225== Invalid write of size 1
 ==23225==    at 0x4A0A308: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:881)
 ==23225==    by 0x52D334: regcache_raw_read (regcache.c:625)
 ==23225==    by 0x45E4D8: h8300_pseudo_register_read (h8300-tdep.c:1171)

shows the problem.  The CCR pseudo register has type length of 1,
while the corresponding CCR raw register has a length of 2 or 4
(depending on mode).  In
sim/h8300/compile.c:sim_{fetch|store}_register we see that the sim
also treats those raw registers (CCR/EXR) as 2 or 4 bytes length.

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

	* h8300-tdep.c (pseudo_from_raw_register)
	(raw_from_pseudo_register): New functions.
	(h8300_pseudo_register_read, h8300_pseudo_register_write): Use
	them.
Explicitly mark vtables as code space

Ports for Hardvard architectures will typically have in their
pointer_to_address hook a check for TYPE_CODE_SPACE in their
"pointer_to_address" gdbarch method.  E.g., rl78's:

  /* Is it a code address?  */
  if (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_FUNC
      || TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_METHOD
      || TYPE_CODE_SPACE (TYPE_TARGET_TYPE (type))
      || TYPE_LENGTH (type) == 4)
    return rl78_make_instruction_address (addr);
  else
    return rl78_make_data_address (addr);

The avr port is similar.

The vtable type is a struct type gdb itself bakes.  Being neither a
function, nor a method, and absent explicit flagging as residing in
code space, ends up being considered data.

This patch marks the type as code when it is created, on the theory
that this is needed for all Hardvard architectures.  I believe this
should make no difference on archs with flat address space.  Testing
on x86-64 GNU/Linux shows no changes.

gdb/
2014-02-12  Pedro Alves  <palves@redhat.com>
	    Kevin Buettner <kevinb@redhat.com>

	* gnu-v3-abi.c (build_gdb_vtable_type): Return a type marked with
	TYPE_INSTANCE_FLAG_CODE_SPACE.

Kevin Buettner, at
<https://sourceware.org/ml/gdb-patches/2014-02/msg00338.html>, writes,
re. rl78:

This patch, for rl78 using the default multilib, fixes 5 failures in
gdb.cp/casts.exp, 2 failures in gdb.cp/class2.exp, 115 failures in
gdb.mi/mi-var-rtti.exp, and 2 failures in gdb.python/py-value.exp.

It introduces 9 failures (regressions) in gdb.mi/mi-var-rtti.exp.

One of the regressions is:

 FAIL: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti

The relevant lines from the log file from a pre-patch test run are as
follows:

 -var-list-children  S.public
 ^done,numchild="1",children=[child={name="S.public.ptr",exp="ptr",numchild="1",type="Base *",thread-id="1"}],has_more="0"
 (gdb)
 PASS: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
 Expecting: \^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"
 Expecting: ^(-var-list-children  S\.public\.ptr  [
 ]+)?(\^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"[
 ]+[(]gdb[)]
 [ ]*)

The same set of lines for the failing (post-patch) run are instead:

 -var-list-children  S.public
 &"warning: can't find linker symbol for virtual table for `Base' value\n"
 &"warning:   found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
 &"warning: can't find linker symbol for virtual table for `Base' value\n"
 &"warning:   found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
 &"warning: can't find linker symbol for virtual table for `Base' value\n"
 &"warning:   found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
 ^done,numchild="1",children=[child={name="S.public.ptr",exp="ptr",numchild="1",type="Base *",thread-id="1"}],has_more="0"
 (gdb)
 FAIL: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
 Expecting: \^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"
 Expecting: ^(-var-list-children  S\.public\.ptr  [
 ]+)?(\^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"[
 ]+[(]gdb[)]
 [ ]*)

Note that the difference between these are the warnings regarding
linker symbols.  Aside from the warnings, the result is the same.
I.e.  gdb produces the correct answer despite the warnings.  The
reason for the other 8 failures is the same: the test harness is not
expecting these warnings.

I spent some time (a while ago) looking at the reason for these
warnings.  As I recall, we are now getting further along in the type
resolution process than we were without my patch.  I.e.  for the
example above, the code in question never got to the point where it
was looking for the specified linker symbol.  So it seems to me that,
at worst, my patch exposes some other problem, but is not directly the
cause of the problem.
FIX EOF detection in PT_IO-based to_xfer_partial implementation.

At least on OpenBSD PT_IO/PIOD_READ_AUXV can return sucessfully without
transferring any bytes.  Arguably a kernel bug, but interpreting this as EOF
seems sensible.

gdb/ChangeLog:

        * inf-ptrace.c (inf_ptrace_xfer_partial): Return TARGET_XFER_EOF
        if a PT_IO ptrace request returns sucessfully but indicates that 0
        bytes were transferred.
Call obsd_init_abi for OpenBSD/sparc64.

gdb/CHangeLog:

        * sparc64obsd-tdep.c (sparc64obsd_init_abi): Call obsd_init_abi.
Add clflushopt, xsaves, xsavec, xrstors

gas/

2014-02-12  Ilya Tocar  <ilya.tocar@intel.com>

	* config/tc-i386.c (cpu_arch): Add .clflushopt, .xsavec, .xsaves.
	* doc/c-i386.texi: Document .xsavec/xsavec/.xsaves/xsaves/
	clflushopt/.clfushopt.

gas/testsuite/

2014-02-12  Ilya Tocar  <ilya.tocar@intel.com>

	* gas/i386/clflushopt-intel.d: New.
	* gas/i386/clflushopt.d: Ditto.
	* gas/i386/clflushopt.s: Ditto.
	* gas/i386/i386.exp: Run new tests.
	* gas/i386/x86-64-clflushopt-intel.d: New.
	* gas/i386/x86-64-clflushopt.d: Ditto.
	* gas/i386/x86-64-clflushopt.s: Ditto.
	* gas/i386/x86-64-xsavec-intel.d: Ditto.
	* gas/i386/x86-64-xsavec.d: Ditto.
	* gas/i386/x86-64-xsavec.s: Ditto.
	* gas/i386/x86-64-xsaves-intel.d: Ditto.
	* gas/i386/x86-64-xsaves.d: Ditto.
	* gas/i386/x86-64-xsaves.s: Ditto.
	* gas/i386/xsavec-intel.d: Ditto.
	* gas/i386/xsavec.d: Ditto.
	* gas/i386/xsavec.s: Ditto.
	* gas/i386/xsaves-intel.d: Ditto.
	* gas/i386/xsaves.d: Ditto.
	* gas/i386/xsaves.s: Ditto.

opcodes/

2014-02-12  Ilya Tocar  <ilya.tocar@intel.com>

	* i386-dis.c (MOD enum): Add MOD_0FC7_REG_3, MOD_0FC7_REG_4,
	MOD_0FC7_REG_5.
	(PREFIX enum): Add PREFIX_0FAE_REG_7.
	(reg_table): Add MOD_0FC7_REG_3, MOD_0FC7_REG_4 MOD_0FC7_REG_5.
	(prefix_table): Add clflusopt.
	(mod_table): Add xrstors, xsavec, xsaves.
	* i386-gen.c (cpu_flag_init): Add CPU_CLFLUSHOPT_FLAGS,
	CPU_XSAVES_FLAGS, CPU_XSAVEC_FLAGS.
	(cpu_flags): Add CpuClflushOpt, CpuXSAVES, CpuXSAVEC.
	* i386-init.h: Regenerate.
	* i386-opc.tbl: Add clflushopt, xrstors, xrstors64, xsaves,
	xsaves64, xsavec, xsavec64.
	* i386-tbl.h: Regenerate.