Fix GDB crash with upstream GCC due to qsort(NULL, ...)

Upstream GCC's new pass '-fisolate-erroneous-paths' may introduce
traps at places where GCC has determined undefined behavior, e.g. when
passing a NULL pointer to a function that defines this argument as
__attribute__(__nonnull__(...)).  In particular this applies to
uniquify_strings(), because it invokes qsort() with NULL when the
'strings' vector is empty.  I hit this problem on s390x when trying to
execute "break main" on a C program.

gdb/
2013-11-12  Andreas Arnez  <arnez@linux.vnet.ibm.com>

	* objc-lang.c (uniquify_strings): Prevent invoking qsort with
	NULL.
	* gdb.base/fileio.exp: Make $dir2 writable after the test is done
	so that "rm -rf $builddir" Just Works.
daily update
* breakpoint.c (bpstat_check_breakpoint_conditions): Assert
bs->stop != 0 on entry.  Update function comment.  Simplify early
exit for frame mismatch.  Reindent rest of function.
crash while re-reading symbols from objfile on ppc-aix.

This patch aims at fixing the following problem, where the user:

  . debugs its program
  . makes a modification and rebuilds it *without exiting the debugger*
  . returns to its debugging session and restarts the inferior

In that situation, the debugger notices that the underlying executable
has changed and that re-reading its symbols is needed. Shortly after
displaying a message informing the user of the situation, GDB crashes:

   (gdb) run
   [...]
   `/[...]/dest' has changed; re-reading symbols.
   zsh: 13434922 segmentation fault (core dumped)

The crash occurs while trying to allocate some memory on the bfd_bfd
obstack.  But, at some point in time, the whole obstack data gets
corrupted, nullified. So the memory allocation fails trying to call
a function at a NULL address. (side note: when debugging GDB in GDB,
top-gdb reports a SIGILL, while the shell makes it look like it was
a SIGSEGV - the discrepancy is not critical to the investigation
and therefore was not explored)

The corruption occurred because the region where the per_bfd data
got free'ed nearly after it got allocated! This is what happens,
in chronological order (see reread_symbols):

  1. GDB notices that the executable has changed, decides to
     re-read its symbols.

  2. Opens a new bfd, unrefs the old one

  3. Calls set_objfile_per_bfd (objfile);

  4. Re-initializes the objfile's obstack:
     obstack_init (&objfile->objfile_obstack);

I think that the normal behavior for set_objfile_per_bfd would
be to search for already-allocated shared per_bfd data, and
allocate new one if not found.  The critical difference between
a platform such as x86_64-linuxe where it works, and ppc-aix,
where it doesn't lies in the fact that bfd-data sharing is not
activated on ppc-aix, and as a result, the per-bfd data gets
allocated on the objfile's obstack instead of in the bfd objalloc:

      /* If the object requires gdb to do relocations, we simply fall
         back to not sharing data across users.  These cases are rare
         enough that this seems reasonable.  */
      if (abfd != NULL && !gdb_bfd_requires_relocations (abfd))
        {
          storage = bfd_zalloc (abfd, sizeof (struct objfile_per_bfd_storage));
          set_bfd_data (abfd, objfiles_bfd_data, storage);
        }
      else
        storage = OBSTACK_ZALLOC (&objfile->objfile_obstack,
                                  struct objfile_per_bfd_storage);

Allocating that per_bfd storage is of course nearly useless since
we end up free-ing right after in step (4) above. Eventually,
the memory region ends up being re-used, hence the corruption
leading to the crash.

This fix was simply to move the call to set_objfile_per_bfd after
the objfile's obstack re-initialization.

gdb/ChangeLog:

        * symfile.c (reread_symbols): Move call to set_objfile_per_bfd
        after re-initialization of OBJFILE's obstack.
Replace "info-ada-exceptions" by "ada-exceptions" in -list-features

Rather than having -list-features report support for the GDB/MI
commands providing access to Ada exception catchpoints with one entry,
and the GDB/MI command providing the list of Ada exceptions with
a second entry, this patch merges it all within one single entry.
This is OK, because all these commands were added within a short
amount of time, and within the same release cycle; and it reduces
a bit the size of the output.

gdb/ChangeLog:

        * mi/mi-main.c (mi_cmd_list_features): Replace "info-ada-exceptions"
        entry with "ada-exceptions".

gdb/doc/ChangeLog:

        * gdb.texinfo (GDB/MI Miscellaneous Commands): Delete
        the documentation of "info-ada-exceptions" in the output
        of the "-list-features" command.  Add the documentation
        of the "ada-exception" entry instead.
fix email address in earlier commit
* breakpoint.c (breakpoint_cond_eval): Fix and enhance comment.
	* rescoff.c (write_coff_file): Use 64-bit alignment for resource
	data.
	(coff_res_to_bin): Likewise.
bfd/

	* elfnn-aarch64.c (elfNN_aarch64_howto_table): Use
	R_AARCH64_TLS_DTPMOD64 instead of R_AARCH64_TLS_DTPMOD;
	likewise for R_AARCH64_TLS_DTPREL and R_AARCH64_TLS_TPREL.

include/elf/

	* aarch64.h: Define R_AARCH64_TLS_DTPMOD64,
	R_AARCH64_TLS_DTPREL64 and R_AARCH64_TLS_TPREL64; guard
	R_AARCH64_TLS_DTPMOD, R_AARCH64_TLS_DTPREL and
	R_AARCH64_TLS_TPREL with RELOC_MACROS_GEN_FUNC.
fix multi-arch-exec for parallel mode

I noticed today that multi-arch-exec.exp was failing in parallel mode.

The bug is that multi-arch-exec.c assumes the non-parallel directory
layout.

This patch fixes the problem using the same "BASEDIR" approach used in
other tests.

Tested both ways on x86-64 Fedora 18.
I'm checking this in.

2013-11-13  Tom Tromey  <tromey@redhat.com>

	* gdb.multi/multi-arch-exec.exp: Define BASEDIR when compiling.
	* gdb.multi/multi-arch-exec.c (main): Use BASEDIR.
Fix regressions caused by const-ify linespec patch:
https://sourceware.org/ml/gdb-patches/2013-10/msg00478.html
PR c++/7539
PR c++/10541

This patch fixes some namespace alias bugs reported in the above bugs.
Links to all mailing list discussion:

https://sourceware.org/ml/gdb-patches/2013-07/msg00649.html
https://sourceware.org/ml/gdb-patches/2013-09/msg00557.html
https://sourceware.org/ml/gdb-patches/2013-11/msg00156.html
Fix PR # dyslexia in ChangeLog for previous commit. It should have
been for c++/7935 (not 7539).
daily update
* breakpoint.c (bpstat_check_breakpoint_conditions): For thread
specific breakpoints, don't evaluate breakpoint condition if
different thread.
ld/ARM: Fix script-type testsuite failure.

Commit 34a79995c4cc34f6f41e2a4b2df477db31b31f0c changed how STT_FILE
symbols were emitted but this testcase got missed in the cleanup.

ld/testsuite/ChangeLog:

2013-11-14  Will Newton  <will.newton@linaro.org>

	* ld-arm/script-type.sym: Remove redundant STT_FILE symbol.
language.h: Add "symtab.h" #include

In addition to the fact that language.h depends on a number of struct
types declared in symtab.h, language.h also depends on an enumerated
type (domain_enum). So language.h should #include "symtab.h".

gdb/ChangeLog:

        * language.h: Add "symtab.h" #include.
New function cli-utils.c:extract_arg_const

This function provides the exact same functionality as extract_arg,
except that it takes a "const char**" instead of a "char **".
It allows us also to re-implement extract_arg almost as a simple
wrapper around the new function.

gdb/ChangeLog:

        Pedro Alves  <palves@redhat.com>
        Joel Brobecker  <brobecker@adacore.com>

        * cli/cli-utils.h (extract_arg_const): Add declaration.
        * cli/cli-utils.c (extract_arg_const): New function.
        (extract_arg): Reimplement using extract_arg_const.
GDB/MI: Add new "--language LANG" command option.

Frontend sometimes need to evaluate expressions that are
language-specific. For instance, Eclipse uses the following
expression to determine the size of an address on the target:

    -data-evaluate-expression "sizeof (void*)"

Unfortunately, if the main of the program being debugged is not C,
this may not work. For instance, if the main is in Ada, you get...

    -data-evaluate-expression "sizeof (void*)"
    ^error,msg="No definition of \"sizeof\" in current context."

... and apparently decides to stop the debugging session as a result.
The  recommendation sent was to specifically set the language to C
before trying to evaluate the expression.  Something such as:

    1. save current language
    2. set language c
    3. -data-evaluate-expression "sizeof (void*)"
    4. Restore language

This has the same disadvantages as the ones outlined in the "Context
Management" section of the GDB/MI documentation regarding setting
the current thread or the current frame, thus recommending the use of
general command-line switches such as --frame, or --thread instead.

This patch follows the same steps for the language, adding a similar
new command option: --language LANG. Example of use:

    -data-evaluate-expression --language c "sizeof (void*)"
    ^done,value="4"

gdb/ChangeLog:

        * mi/mi-parse.h (struct mi_parse) <language>: New field.
        * mi/mi-main.c (mi_cmd_execute): Temporarily set language to
        PARSE->LANGUAGE during command execution, if set.
        * mi/mi-parse.c: Add "language.h" #include.
        (mi_parse): Add parsing of "--language" command option.

        * NEWS: Add entry mentioning the new "--language" command option.

gdb/testsuite/ChangeLog:

        * gdb.mi/mi-language.exp: New file.

gdb/doc/ChangeLog:

        * gdb.texinfo (Show): Add xref anchor for "show language" command.
        (Context management): Place current subsection text into its own
        subsubsection.  Add new subsubsection describing the "--language"
        command option.