Make it easy to make --disable-werror the default for both binutils and gdb

The goal of this patch is to provide an easy way to make
--disable-werror the default when building binutils, or the parts
of binutils that need to get built when building GDB. In development
mode, we want to continue making -Werror the default with GCC.
But, when making releases, I think we want to make it as easy as
possible for regular users to successfully build from sources.

GDB already has this kind of feature to turn -Werror as well as
the use of the libmcheck library. As GDB Release Manager, I take
advantage of it to turn those off after having cut the branch.
I'd like to be able to do the same for the binutils bits. And
perhaps Tristan will want to do the same for his releases too
(not sure, binutils builders might be a little savvier than GDB
builders).

This patch introduces a new file, called development.sh, which
just sets a variable called $development. In our development branches
(Eg. "master"), it's set to true. But setting it to false would allow
us to change the default behavior of various development-related
features to be turned off; in this case, it turns off the use of
-Werror by default (use --enable-werror to turn it back on).

bfd/ChangeLog:

        * development.sh: New file.
        * warning.m4 (AM_BINUTILS_WARNINGS): Source bfd/development.sh.
        Make -Werror the default with GCC only if DEVELOPMENT is true.
        * Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add
        $(srcdir)/development.sh.
        * Makefile.in, configure: Regenerate.

binutils/ChangeLog:

        * Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
        bfd's development.sh.
        * Makefile.in, configure: Regenerate.

gas/ChangeLog:

        * Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
        bfd's development.sh.
        * Makefile.in, configure: Regenerate.

gold/ChangeLog:

        * Makefile.am (CONFIG_STATUS_DEPENDENCIES): New.
        * Makefile.in, configure: Regenerate.

gprof/ChangeLog:

        * Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
        bfd's development.sh.
        * Makefile.in, configure: Regenerate.

ld/ChangeLog:

        * Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
        bfd's development.sh.
        * Makefile.in, configure: Regenerate.

opcodes/ChangeLog:

        * Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add dependency on
        bfd's development.sh.
        * Makefile.in, configure: Regenerate.

gdb/ChangeLog:

        * development.sh: Delete.
        * Makefile.in (config.status): Adjust dependency on development.sh.
        * configure.ac: Adjust development.sh source call.
        * configure: Regenerate.

gdb/gdbserver/ChangeLog:

        * configure.ac: Adjust development.sh source call.
        * Makefile.in (config.status): Adjust dependency on development.sh.
        * configure: Regenerate.

Tested on x86_64-linux by building two ways: One with DEVELOPMENT
set to true, and one with DEVELOPMENT set to false. In the first
case, I could see the use of -Werror, while it disappeared in
the second case.
PR mi/15806: Fix quoting of async events

Original patch:
https://sourceware.org/ml/gdb-patches/2014-04/msg00552.html

New in v2:
* In remote.c:escape_buffer, pass '\\' to fputstrn_unfiltered/printchar to
make sure backslashes are escaped in remote debug output.
* Updated function documentation for printchar.

See updated ChangeLog below.

--------------------

The quoting in whatever goes in the event_channel of MI is little bit broken.

Link for the lazy:
  https://sourceware.org/bugzilla/show_bug.cgi?id=15806

Here is an example of a =library-loaded event with an ill-named directory,
/tmp/how"are\you (the problem is present with every directory on Windows since
it uses backslashes as a path separator). The result will be the following:

=library-loaded,id="/tmp/how"are\\you/libexpat.so.1",...

The " between 'how' and 'are' should be escaped.

Another bad behavior is double escaping in =breakpoint-created, for example:

=breakpoint-created,bkpt={...,fullname="/tmp/how\\"are\\\\you/test.c",...}

The two backslashes before 'how' should be one and the four before 'you' should
be two.

The reason for this is that when sending something to an MI console, escaping
can take place at two different moments (the actual escaping work is always
done in the printchar function):

1. When generating the content, if ui_out_field_* functions are used. Here,
fields are automatically quoted with " and properly escaped. At least
mi_field_string does it, not sure about mi_field_fmt, I need to investigate
further.

2. When gdb_flush is called, to send the data in the buffer of the console to
the actual output (stdout). At this point, mi_console_raw_packet takes the
whole string in the buffer, quotes it, and escapes all occurences of the
quoting character and backslashes. The event_channel does not specify a quoting
character, so quotes are not escaped here, only backslashes.

The problem with =library-loaded is that it does use fprintf_unfiltered, which
doesn't do escaping (so, no #1). When gdb_flush is called, backslashes are
escaped (#2).

The problem with =breakpoint-created is that it first uses ui_out_field_*
functions to generate its output, so backslashes and quotes are escaped there
(#1). backslashes are escaped again in #2, leading to an overdose of
backslashes.

In retrospect, there is no way escaping can be done reliably in
mi_console_raw_packet for data that is already formatted, such as
event_channel. At this point, there is no way to differentiate quotes that
delimit field values from those that should be escaped. In the case of other MI
consoles, it is ok since mi_console_raw_packet receives one big string that
should be quoted and escaped as a whole.

So, first part of the fix: for the MI channels that specify no quoting
character, no escaping at all should be done in mi_console_raw_packet (that's
the change in printchar, thanks to Yuanhui Zhang for this). For those channels,
whoever generates the content is responsible for proper quoting and escaping.
This will fix the =breakpoint-created kind of problem.

Second part of the fix is to make =library-loaded generate content that is
properly escaped. For this, we use ui_out_field_* functions, instead of one big
fprintf_unfiltered. =library-unloaded suffered from the same problem so it is
modified as well. There might be other events that need fixing too, but that's
all I found with a quick scan. Those that use fprintf_unfiltered but whose sole
variable data is a %d are not critical, since it won't generate a " or a \.

Finally, a test has been fixed, as it was expecting an erroneous output.
Otherwise, all other tests that were previously passing still pass (x86-64
linux).

gdb/ChangeLog:

2014-06-02  Simon Marchi  <simon.marchi@ericsson.com>

	PR mi/15806
	* utils.c (printchar): Don't escape at all if quoter is NUL.
	Update function documentation to clarify effect of parameter
	QUOTER.
	* remote.c (escape_buffer): Pass '\\' as the quoter to
	fputstrn_unfiltered.
	* mi/mi-interp.c (mi_solib_loaded): Use ui_out_field_* functions to
	generate the output.
	(mi_solib_unloaded): Same.

gdb/testsuite/ChangeLog:

2014-06-02  Simon Marchi  <simon.marchi@ericsson.com>

	* gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify): Fix
	erroneous dprintf expected input.
guile: Type-check the argument to 'history-append!'.

gdb/
2014-06-05  Ludovic Courtès  <ludo@gnu.org>

	* guile/scm-value.c (gdbscm_history_append_x): Use
	'vlscm_get_value_smob_arg_unsafe' instead of
	'vlscm_scm_to_value'.

gdb/testsuite/
2014-06-05  Ludovic Courtès  <ludo@gnu.org>

	* gdb.guile/scm-value.exp (test_value_in_inferior): Add test
	"history-append! type error".
daily update
Fix the race in gdb.threads/staticthreads.exp

The code in gdb.threads/staticthreads.exp about checking the value of
tlsvar in main thread is racy, because when child thread hits
breakpoint, the main thread may not go into pthread_join yet, and
may not be unwind to main.

This patch is to move the line setting breakpoint on after sem_wait,
so that the child thread will hit breakpoint after main thread calls
sem_post.  IOW, when child thread hits breakpoint, the main thread is
in either sem_post or pthread_join.  "up 10" can unwind main thread to
main.

gdb/testsuite:

2014-06-06  Yao Qi  <yao@codesourcery.com>

	* gdb.threads/staticthreads.c (thread_function): Move the line
	setting breakpoint on forward.
	* gdb.threads/staticthreads.exp: Update comments.
[AArch64] Fix the documentation on :pg_hi21:
symfile, vdso: remove target sections

Target sections added by the add-symbol-file-from-memory command are not
removed when the process exits.  In fact, they are not removed, at all.

This causes GDB to crash in gdb.base/break-interp.exp.

Change the owner of those target sections to the object file generated in
symbol_file_add_from_memory and generalize the free_objfile observer in
symfile.c to remove target sections of any freed object file.
Skip hbreak-unmapped.exp if memory at address 0 is readable

hbreak-unmapped.exp assumes that memory at address 0 is unmapped or
unreadable, but on bare metal or uclinux targets, memory at address
0 is readable.  For example, on arm-none-eabi, the vector table base
address is 0x0.

hbreak *0^M
Hardware assisted breakpoint 3 at 0x0: file
/scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S,
line 25.^M
(gdb) FAIL: gdb.base/hbreak-unmapped.exp: hbreak *0
info break^M
Num     Type           Disp Enb Address    What^M
3       hw breakpoint  keep y   0x00000000
/scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S:25^M
(gdb) FAIL: gdb.base/hbreak-unmapped.exp: info break shows hw breakpoint
delete $bpnum

This patch is to check whether address 0 is readable via command 'x 0'.
If it is, skip the test.

gdb/testsuite:

2014-06-06  Yao Qi  <yao@codesourcery.com>

	* gdb.base/hbreak-unmapped.exp: Read memory at address 0.  If
	readable, skip the test.
add -q in help info and doc
Remove preprocessor conditionals for ANSI-standard signals

The six signals SIGINT, SIGILL, SIGABRT, SIGFPE, SIGSEGV and SIGTERM
are ANSI-standard and thus guaranteed to be available.  This patch
removes all preprocessor conditionals relating to these symbols.

gdb/
2014-06-06  Gary Benson  <gbenson@redhat.com>

	* common/signals.c: Remove preprocessor conditionals for
	always-defined signals SIGINT, SIGILL, SIGABRT, SIGFPE,
	SIGSEGV and SIGTERM.
	* proc-events.c: Likewise.

gdb/testsuite/
2014-06-06  Gary Benson  <gbenson@redhat.com>

	* gdb.base/call-signals.c: Remove preprocessor conditionals
	for always-defined signals SIGINT, SIGILL, SIGABRT, SIGFPE,
	SIGSEGV and SIGTERM.
	* gdb.base/sigall.c: Likewise.
	* gdb.base/unwindonsignal.c: Likewise.
	* gdb.reverse/sigall-reverse.c: Likewise.
update ChangeLog
Tweak gdb.base/async.exp

I see two fails in async.exp on arm-none-eabi target:

nexti&^M
(gdb) 0x000001ba        14       x = 5; x = 5;^M
completed.^M
FAIL: gdb.base/async.exp: nexti&
finish&^M
Run till exit from #0  0x000001ba in foo () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:14^M
(gdb) 0x000001e6 in main () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:32^M
32       y = foo ();^M
Value returned is $1 = 8^M
completed.^M
FAIL: gdb.base/async.exp: finish&

The corresponding test is "test_background "nexti&" "" ".*y = 3.*"",
and it assumes that GDB "nexti" into the next source line.  It is wrong
on arm.  After "nexti", it still stops at the same source line, and it
fails.

When gdb does "finish", if the PC is in the middle of a source line,
the PC address is printed too.  See stack.c:print_frame,

  if (opts.addressprint)
    if (!sal.symtab
	|| frame_show_address (frame, sal)
	|| print_what == LOC_AND_ADDRESS)
      {
	annotate_frame_address ();
	if (pc_p)
	  ui_out_field_core_addr (uiout, "addr", gdbarch, pc);
	else
	  ui_out_field_string (uiout, "addr", "<unavailable>");
	annotate_frame_address_end ();
	ui_out_text (uiout, " in ");
      }

frame_show_address checks whether PC is the middle of a source line.
Since after "nexti", the inferior stops at the middle of a source line,
when we do "finish" the PC address is displayed.

In sum, GDB works well, but test case needs update.  This patch is to
add a statement at the same line to make sure "nexti" doesn't go to
the new line, match the next instruction address in the output and
match the hex address the output of "finish".

gdb/testsuite:

2014-06-06  Yao Qi  <yao@codesourcery.com>

	* gdb.base/async.c (foo): Add one statement.
	* gdb.base/async.exp: Get the next instruction address and
	match the output of "nexti" by instruction address.  Match
	the hex address in the output of "finish".
Restrict the pattern in gdb.base/jit.exp

I see the following fail in some thumb multi-lib in arm-none-linux-gnueabi,

info function jit_function^M
All functions matching regular expression "jit_function":^M
^M
Non-debugging symbols:^M
0x00000790  __real_jit_function_XXXX^M
0x0000079c  __jit_function_XXXX_from_arm^M
0x0000079c  jit_function_0000^M
0x00000790  __real_jit_function_XXXX^M
0x0000079c  __jit_function_XXXX_from_arm^M
0x0000079c  jit_function_0001^M
(gdb) FAIL: gdb.base/jit.exp: one_jit_test-2: info function jit_function

the test expects to see only jit_function_0000 and jit_function_0001

one_jit_test 2 "${hex}  jit_function_0000\[\r\n\]+${hex}  jit_function_0001"

Symbols with the prefix "__real_" or suffix "_from_arm" is generated
by gcc/ld for arm/thumb interworking.

This patch is to restrict the pattern from "jit_function" to
"^jit_function", the output becomes expected.

gdb/testsuite:

2014-06-06  Yao Qi  <yao@codesourcery.com>

	* gdb.base/jit.exp (one_jit_test): Restrict the pattern
	from "jit_function" to "^jit_function".
break-unload-file.exp: Fix typo.

s/is not pending/is pending/

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

	* gdb.base/break-unload-file.exp: Fix typo.
sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux.

I noticed that sss-bp-on-user-bp-2.exp is racy on native GNU/Linux.  I
sometimes still see an int3 in the disassembly:

 (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: set debug target 0
 disassemble test
 Dump of assembler code for function test:
    0x0000000000400590 <+0>:     push   %rbp
    0x0000000000400591 <+1>:     mov    %rsp,%rbp
    0x0000000000400594 <+4>:     nop
 => 0x0000000000400595 <+5>:     int3
    0x0000000000400596 <+6>:     pop    %rbp
    0x0000000000400597 <+7>:     retq
 End of assembler dump.
 (gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: before/after disassembly matches

Enabling infrun/target debug logs, we can see the problem.
Simplified, that's:

 (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
 stepi_del_break
 infrun: clear_proceed_status_thread (process 25311)
 infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25311] at 0x400594
 LLR: PTRACE_SINGLESTEP process 25311, 0 (resume event thread)
 target_resume (25311, step, 0)
 native:target_xfer_partial (3, (null), 0x0, 0x32dce4c, 0x400595, 1) = 0, 0
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 (gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG]

0x400595 is the address of the breakpoint, and "= 0" is
TARGET_XFER_EOF.  That's default_memory_remove_breakpoint trying to
remove the breakpoint, but failing.

The problem is that we had just resumed the target and the native
GNU/Linux target can't read memory off of a running thread.  Most of
the time, we get "lucky", because we manage to read memory before the
kernel actually schedules the target to run.

So just give up and skip the test on any target that uses hardware
stepping, not just remote targets.

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

	* gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step)
	in target debug output instead of looking at RSP packets,
	disabling the test on any target that uses hardware stepping.
	Update comments.
* gdb.guile/scm-frame-args.c (foo): Tweak to work with gcc 4.6.3.
Add support for guile 2.0.5.

	* guile/guile-internal.h (gdbscm_guile_major_version): Declare.
	(gdbscm_guile_minor_version, gdbscm_guile_micro_version): Declare.
	(gdbscm_guile_version_is_at_least): Declare.
	(gdbscm_scm_string_to_int): Declare.
	* guile/guile.c (gdbscm_guile_major_version): New global.
	(gdbscm_guile_minor_version, gdbscm_guile_micro_version): New globals.
	(guile_datadir): New static global.
	(gdbscm_guile_data_directory): New function.
	(initialize_scheme_side): Update.
	(misc_guile_functions): Add guile-data-directory.
	(initialize_gdb_module): Fetch guile version number.
	* guile/lib/gdb.scm: Remove call to add-to-load-path.
	* guile/lib/gdb/init.scm (%initialize!): Ditto.
	* guile/lib/gdb/boot.scm: Use guile-data-directory.
	* guile/scm-exception.c (gdbscm_print_exception_with_stack): Fix
	comments.
	* guile/scm-string.c (gdbscm_scm_string_to_int): New function.
	* guile/scm-utils.c (gdbscm_guile_version_is_at_least): New function.
	* guile/scm-value.c (gdbscm_value_to_string): Only call
	scm_port_conversion_strategy if Guile version >= 2.0.6.

	doc/
	* guile.texi (Guile Configuration): Document guile-data-directory.
fix email address of previous checkins
Strip .debug_gnu_pubnames and .debug_gnu_pubtypes when building .gdb_index.

When not stripping those sections, there was a bug where gold was incorrectly
adjusting section-relative offsets by the offset of the input section within
the output section. That adjustment was both unnecessary and wrong, causing
gold to miss a number of debug entries that should have been added to
.gdb_index.  (With stripping, the adjustment was always 0, so the bug in
dwarf_reader.cc would have been hidden by the change to layout.cc.)

gold/
	* dwarf_reader.h (Dwarf_pubnames_table): Remove output_section_offset_.
	* dwarf_reader.cc (Dwarf_pubnames_table::read_section): Likewise.
	(Dwarf_pubnames_table::read_header): Likewise.
	* layout.cc (gdb_fast_lookup_sections): Add .debug_gnu_pubnames and
	.debug_gnu_pubtypes.
daily update