Hi 
On Tue, Sep 11, 2018 at 09:40:57AM -0600, Tom Tromey wrote:
> >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
> 
> Joel> +  long max_number_of_symbols
> Joel> +    = bfd_get_symtab_upper_bound (abfd) / sizeof (asymbol *);
> Joel> +  if (max_number_of_symbols <= 0)
> Joel> +    return GDB_OSABI_UNKNOWN;
> 
> Joel> +  std::vector<asymbol *> symbol_table (max_number_of_symbols);
> Joel> +  number_of_symbols = bfd_canonicalize_symtab (abfd, symbol_table.data ());
> Joel> +  if (number_of_symbols <= 0)
> Joel> +    return GDB_OSABI_UNKNOWN;
> Joel> +  gdb_assert (number_of_symbols <= max_number_of_symbols);
> Joel> +  symbol_table.resize (number_of_symbols);
> 
> I looked, and some spots doing this just use xmalloc and manage it
> manually.  machoread though uses gdb::def_vector; which is nice since it
> doesn't clear the memory.

Indeed; I think the std::vector approach I had also had that property,
if I understand the spec correctly. Before I could see this suggestion,
I thought gdb::unique_xmalloc_ptr kind of conveyed the idea that
this was more of a C object (due to the use with BFD), than a C++
object, so used that instead and found the code to be slightly
smaller. The approach has its drawbacks as well, so maybe if people
have a preference for using the gdb::def_vector, I can do that too.

> No idea why it isn't working for you, the patch looks ok to me.
> Sorry about this.  If you'd rather get it in, I can remove the cleanup later.

Thanks. I didn't want to do that, because it would have put the burden
on you, and new code shouldn't add constructs we are actively trying
to remove.

Luckily, I found that the issue was due to some instability of
the target, and could repeat the same errors with AdaCore version
of GDB. Our testsuite framework is capable of dealing with that,
by shutting down and restarting the development environment before
re-trying the testcase. This is actually activated by default, but
like the idiot that I am, I had explicitly turned it off!

The testing is running as we speak, but because it's one testcase
at a time, I will not have the results until tomorrow. But so far,
so good, so fingers crossed...

In the menatime, attached is the patch I am testing.

gdb/ChangeLog:

        * defs.h (enum gdb_osabi): Add GDB_OSABI_PIKEOS.
        * osabi.c (gdb_osabi_names): Add name for GDB_OSABI_PIKEOS.
        * arm-pikeos-tdep.c: New file.
        * configure.tgt: Add arm-pikeos-tdep.o to the case of ARM
        embedded system.
        * Makefile.in (ALL_TARGET_OBS): Add arm-pikeos-tdep.o.

Note the discussion with Pedro about getting the vendor to enhance
the stub to tell GDB that hardware single stepping is not supported
(https://www.sourceware.org/ml/gdb-patches/2018-09/msg00345.html).
We'll work with the vendor, and so this patch would be applied as
a stop gap measure. But it's unclear if and when the stub would be
enhanced, allowing us to remove this patch.

Thanks!
-- 
Joel