Fix --defsym to copy symbol attributes.

Alan Modra committed a patch to Gnu ld to fix a problem encountered on
PPC where the --defsym option wasn't copying the st_other bits to the
newly-defined symbol.

    https://sourceware.org/ml/binutils/2014-07/msg00094.html

Gold has the same problem, and additionally wasn't copying the symbol type.
This patch fixes both problems, by copying the symbol type, visibility, and
the remaining st_other bits to the new symbol for --defsym=sym1=sym2
assignments.

gold/
	* expression.cc (struct Expression::Expression_eval_info): Add
	new fields type_pointer, vis_pointer, and nonvis_pointer.
	(Expression::eval_maybe_dot): Add type_pointer, vis_pointer, and
	nonvis_pointer parameters. Adjust all calls.
	(Symbol_expression::value): Update type, visibility, and nonvis bits
	in caller.
	* script.cc (Symbol_assignment::sized_finalize): Update type,
	visibility, and remaining st_other bits for new symbol.
	* script.h: (Expression::eval_maybe_dot): Add type_pointer,
	vis_pointer, and nonvis_pointer parameters.
	* symtab.h (Symbol::set_type): New method.

	* testsuite/Makefile.am (defsym_test): New test.
	* testsuite/Makefile.in: Regenerate.
	* testsuite/defsym_test.c: New file.
	* testsuite/defsym_test.sh: New file.
Improve MI -var-info-path-expression for nested struct/union case.

  https://sourceware.org/ml/gdb-patches/2014-05/msg00383.html

The MI command -var-info-path-expression currently does not handle
non-anonymous structs / unions nested within other structs / unions,
it will skip parts of the expression.  Consider this example:

  ## START EXAMPLE ##
  $ cat ex.c
  #include <string.h>

  int
  main ()
  {
    struct s1
    {
      int a;
    };

    struct ss
    {
      struct s1 x;
    };

    struct ss an_ss;
    memset (&an_ss, 0, sizeof (an_ss));
    return 0;
  }
  $ gcc -g -o ex.x ex.c
  $ gdb ex.x
  (gdb) break 18
  Breakpoint 1 at 0x80483ba: file ex.c, line 18.
  (gdb) run
  Starting program: /home/user/ex.x

  Breakpoint 1, main () at ex.c:18
  18	  return 0;
  (gdb) interpreter-exec mi "-var-create an_ss * an_ss"
  (gdb) interpreter-exec mi "-var-list-children an_ss"
  ^done,numchild="1",children=[child={name="an_ss.x",exp="x",numchild="1",type="struct s1",thread-id="1"}],has_more="0"
  (gdb) interpreter-exec mi "-var-list-children an_ss.x"
  ^done,numchild="1",children=[child={name="an_ss.x.a",exp="a",numchild="0",type="int",thread-id="1"}],has_more="0"
  (gdb) interpreter-exec mi "-var-list-children an_ss.x.a"
  ^done,numchild="0",has_more="0"
  (gdb) interpreter-exec mi "-var-info-path-expression an_ss.x.a"
  ^done,path_expr="(an_ss).a"
  (gdb) print (an_ss).a
  There is no member named a.
  ## END EXAMPLE ##

Notice that the path expression returned is wrong, and as a result
the print command fails.

This patch adds a new method to the varobj_ops structure called
is_path_expr_parent, to allow language specific control over finding
the parent varobj, the current logic becomes the C/C++ version and is
extended to handle the nested cases.  No other language currently uses
this code, so all other languages just get a default method.

With this patch, the above example now finishes like this:

  ## START EXAMPLE ##
  $ gdb ex.x
  (gdb) break 18
  Breakpoint 1 at 0x80483ba: file ex.c, line 18.
  (gdb) run
  Starting program: /home/user/ex.x

  Breakpoint 1, main () at ex.c:18
  18	  return 0;
  (gdb) interpreter-exec mi "-var-list-children an_ss"
  ^done,numchild="1",children=[child={name="an_ss.x",exp="x",numchild="1",type="struct s1",thread-id="1"}],has_more="0"
  (gdb) interpreter-exec mi "-var-list-children an_ss.x"
  ^done,numchild="1",children=[child={name="an_ss.x.a",exp="a",numchild="0",type="int",thread-id="1"}],has_more="0"
  (gdb) interpreter-exec mi "-var-list-children an_ss.x.a"
  ^done,numchild="0",has_more="0"
  (gdb) interpreter-exec mi "-var-info-path-expression an_ss.x.a"
  ^done,path_expr="((an_ss).x).a"
  (gdb) print ((an_ss).x).a
  $1 = 0
  ## END EXAMPLE ##

Notice that the path expression is now correct, and the print is a
success.

gdb/ChangeLog:

	* ada-varobj.c (ada_varobj_ops): Fill in is_path_expr_parent
	field.
	* c-varobj.c (c_is_path_expr_parent): New function, moved core
	from varobj.c, with additional checks.
	(c_varobj_ops): Fill in is_path_expr_parent field.
	(cplus_varobj_ops): Fill in is_path_expr_parent field.
	* jv-varobj.c (java_varobj_ops): Fill in is_path_expr_parent
	field.
	* varobj.c (is_path_expr_parent): Call is_path_expr_parent varobj
	ops method.
	(varobj_default_is_path_expr_parent): New function.
	* varobj.h (lang_varobj_ops): Add is_path_expr_parent field.
	(varobj_default_is_path_expr_parent): Declare new function.

gdb/testsuite/ChangeLog:

	* gdb.mi/var-cmd.c (do_nested_struct_union_tests): New function
	setting up test structures.
	(main): Call new test function.
	* gdb.mi/mi2-var-child.exp: Create additional breakpoint in new
	test function, continue into test function and walk test
	structures.
Fix "attach" command vs user input race

On async targets, a synchronous attach is done like this:

   #1 - target_attach is called (PTRACE_ATTACH is issued)
   #2 - a continuation is installed
   #3 - we go back to the event loop
   #4 - target reports stop (SIGSTOP), event loop wakes up, and
        attach continuation is called
   #5 - among other things, the continuation calls
        target_terminal_inferior, which removes stdin from the event
        loop

Note that in #3, GDB is still processing user input.  If the user is
fast enough, e.g., with something like:

  echo -e "attach PID\nset xxx=1" | gdb

... then the "set" command is processed before the attach completes.

We get worse behavior even, if input is a tty and therefore
readline/editing is enabled, with e.g.,:

 (gdb) attach PID\nset xxx=1

we then crash readline/gdb, with:

 Attaching to program: attach-wait-input, process 14537
 readline: readline_callback_read_char() called with no handler!
 Aborted
 $

Fix this by calling target_terminal_inferior before #3 above.

The test covers both scenarios by running with editing/readline forced
to both on and off.

gdb/
2014-07-09  Pedro Alves  <palves@redhat.com>

	* infcmd.c (attach_command_post_wait): Don't call
	target_terminal_inferior here.
	(attach_command): Call it here instead.

gdb/testsuite/
2014-07-09  Pedro Alves  <palves@redhat.com>

	* gdb.base/attach-wait-input.exp: New file.
	* gdb.base/attach-wait-input.c: New file.
daily update
Tweak gdb.trace/tfile.c for thumb mode

We see the fail below happens on thumb related multi-libs
(-mthumb -march={armv4t,armv7-a}),

target tfile tfile-basic.tf ^M
warning: Uploaded tracepoint 1 has no source location, using raw address^M
warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M
Tracepoint 3 at 0x8958: file /scratch/yqi/arm-none-linux-gnueabi/src/gdb-trunk/gdb/testsuite/gdb.trace/tfile.c, line 91.^M
Created tracepoint 3 for target's tracepoint 1 at 0x8959.^M
warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M
warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M
warning: Breakpoint address adjusted from 0x00008959 to 0x00008958.^M
(gdb) FAIL: gdb.trace/tfile.exp: complete-command 'target tfile'

The address of write_basic_trace_file is two-bytes aligned,

(gdb) p write_basic_trace_file
$1 = {void (void)} 0x8958 <write_basic_trace_file>

but the ld sets the LSB of every reference to the function address
(indicating the address is in thumb mode), so "&write_basic_trace_file"
in the program becomes 0x8959, which is saved in the trace file.  That
is why the warnnings are emitted.

This patch is to clear the LSB of the function address written to trace
file in thumb and thumb2 mode.  This patch fixes the fail above.

gdb/testsuite:

2014-07-10  Yao Qi  <yao@codesourcery.com>

	* gdb.trace/tfile.c (write_basic_trace_file)
	[__thumb__||__thumb2__]: Clear the Thumb bit of the function
	address written to trace file.
[Patch, microblaze]: Add wdc.ext.clear and wdc.ext.flush insns

Added two new instructions, wdc.ext.clear and wdc.ext.flush,
to enable MicroBlaze to flush an external cache, which is
used with the new coherency support for multiprocessing.

Signed-off-by:nagaraju <nmekala@xilix.com>
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
[Patch, microblaze]: Add mlittle-endian and mbig-endian flags

Added support in gas for mlittle-endian and mbig-endian flags
as options.

Updated show usage for MicroBlaze specific assembler options
to include new entries.

Signed-off-by:nagaraju <nmekala@xilix.com>
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
[Patch, microblaze]: Initial port of microblaze core reading support

Added support for reading notes in linux core dumps
Support for reading of PRSTATUS and PSINFO information for rebuilding
".reg" sections of core dumps at run time.

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
[Patch, microblaze]: Communicate in larger blocks with the target

Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
[Patch, microblaze]: Add mb singlestepping.

Fix prologue analysis for little-endian.
Always provide a frame base.

Signed-off-by: Edgar E. Iglesias <edgar@axis.com>
[Patch, microblaze]: Add initial port of linux gdbserver

add gdb_proc_service_h to gdbserver microblaze-linux

gdbserver needs to initialise the microblaze registers

other archs use this step to run a *_arch_setup() to carry out all
architecture specific setup - may need to add in future

 * add linux-ptrace.o to gdbserver configure
 * gdb/configure.tgt: Set build_gdbserver=yes
 * Update breakpoint opcode
 * fix segfault on connecting gdbserver
 * add microblaze_linux_memory_remove_breakpoint
 * add set_solib_svr4_fetch_link_map_offsets
 * add set_gdbarch_fetch_tls_load_module_address
 * Force reading of r0 as 0, prevent stores

Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com>
Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com>
[Patch, microblaze]: Add slr and shr regs and little-endian breakpoint

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
[Patch, microblaze]: Added Backtrace support to GDB

Added backtrace support without debugging information.

Earlier backtrace used to work only when debug information is available.
Previous pc & sp values are calculated incorrectly due to which backtrace
was failing.

In this patch, previous frame sp & pc values are calculated correctly
in microblaze_frame_cache function and supplied them to
microblaze_frame_prev_register function

Signed-off-by:nagaraju <nmekala@xilix.com>
[Patch, microblaze]: Initial support for native gdb

microblaze: Follow PPC method of getting setting registers
using PTRACE PEEK/POKE

Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com>
[Patch, gdb]: Robustify inline function support

Signed-off-by: Edgar E. Iglesias <edgar@axis.com>
[Patch, gdb]: Fix debug message when register is unavailable

Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
[LOCAL]: Disable the warning message for eh_frame_hdr

Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
[LOCAL]: Fix relaxation of assembler resolved references
[LOCAL]: Fixup debug_loc sections after linker relaxation

Adds a new reloctype R_MICROBLAZE_32_NONE, used for passing
reloc info from the assembler to the linker when the linker
manages to fully resolve a local symbol reference.

This is a workaround for design flaws in the assembler to
linker interface with regards to linker relaxation.

Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
[LOCAL]: upstream change to garbage collection sweep causes mb regression

Upstream change for PR13177 now clears the def_regular during gc_sweep of a
section. (All other archs in binutils/bfd/elf32-*.c received an update
to a warning about unresolvable relocations - this warning is not present
in binutils/bfd/elf32-microblaze.c, but this warning check would not
prevent the error being seen)

The visible issue with this change is when running a c++ application
in Petalinux which links libstdc++.so for exception handling it segfaults
on execution.

This does not occur if static linking libstdc++.a, so its during the
relocations for a shared lib with garbage collection this occurs

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>