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.