do not use dwarf2_per_objfile in dwarf2_per_objfile_free.

This patch fixes a case of multiple calls freeing the same data
while free-ing objfiles that have child objfiles (separate debug
info, as is the case on Darwin targets).

Following the code, free_objfile_separate_debug iterates over
all child objfiles of the parent objfile, calling free_objfile:

  for (child = objfile->separate_debug_objfile; child;)
    {
      struct objfile *next_child = child->separate_debug_objfile_link;
      free_objfile (child);
      child = next_child;
    }

This causes, among other things, the free'ing of the child objfile's
private data:

  /* Discard any data modules have associated with the objfile.  The function
     still may reference objfile->obfd.  */
  objfile_free_data (objfile);

This indirectly calls(back) dwarf2_per_objfile_free, which tries
to free the dwarf2read-specific data by using the dwarf2_per_objfile
global, eg:

  for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix)

Even if we were lucky enough the first time around that this global
actually corresponds to the objfile being destroyed, the global
will still have the same value at the second iteration, and thus
become dangling. Indeed, after dwarf2_per_objfile_free returns
eventually back to free_objfile, free_objfile then deallocates
its objfile_obstack, where the dwarf2_per_objfile is allocated.

Ironically, there should be no need to access that global at all,
here, since the data is passed as an argument of the callback.
And it looks like the dwo/dwp/[...]-handling code is in fact already
using that argument, rather than the global.

This patch thus fixes the problem by doing the same, replacing
all references to DWARF2_PER_OBJFILE by uses of DATA instead.

gdb/ChangeLog:

        * dwarf2read.c (dwarf2_per_objfile): Replace uses of
        DWARF2_PER_OBJFILE by uses of DATA instead.
[Darwin] Fix cleanup leak in machoread.c:macho_symfile_read

This patch fixes a cleanup leak in macho_symfile_read (symbol_table):

          symbol_table = (asymbol **) xmalloc (storage_needed);
          make_cleanup (xfree, symbol_table);

Unfortunately, fixing the leak alone triggers a crash which occurs
while loading the symbols from an executable:

    % gdb
    (gdb) file g_exe
    [SIGSEGV]

The crash is caused by the fact that performing the cleanup
right after the call to macho_symtab_read, as currently done,
is too early.

Indeed, references to this symbol_table get saved in the oso_vector
global during the call to macho_symtab_read via calls to
macho_register_oso, and those references then get accessed
later on, when processing all the OSOs that got pushed (see
call to macho_symfile_read_all_oso).

This patch prevents this by using one single cleanup queue for
the entire function, rather than having additional separate
cleanup queues (Eg: for the handling of the minimal symbols),
thus preventing the premature free'ing of the minimal_symbols
array.

Secondly, this patch takes this opportunity for avoiding the use
of the oso_vector global, thus making it simpler to track its
lifetime.

gdb/ChangeLog:

        * machoread.c (oso_vector): Delete this global.
        (macho_register_oso): Add new parameter "oso_vector_ptr".
        Use it instead of the "oso_vector" global.
        (macho_symtab_read, macho_symfile_read_all_oso): Likewise.
        (macho_symfile_read): Use a local oso_vector, to be free'ed
        at the end of this function, in place of the old "oso_vector"
        global.  Update various function calls accordingly.  Use one
        single cleanup chain for the entire function.