[RFA,v2] arm-pikeos: software single step

  > (not sure why the From address is y@eu.adacore.com, I'll replace it with
> Joel's).

It was my mistake answering "y" rather than just typing answer
to use my email address as the default when "git send-email"
asked me about it. Sorry, and thanks for fixing!

> > +  symbol_table = (asymbol **) xmalloc (storage_needed);
> > +  make_cleanup (xfree, symbol_table);
> 
> It would make Tom really happy if you could avoid introducing a cleanup :).
> I would suggest using an std::vector<asymbol *>.  If you'd rather not do it
> it's not a big deal, we can change it after.

Attached is the patch I am testing. I am wondering if this is the best
way, though. What do you think?

One question I asked myself is whether we needed the std::vector at
all, as the building of the vector is a bit clunky in this situation.
As I understand it, this is mostly to automate the destruction of
the array. I was wondering whether we could do without the std::vector
entirely, and just handle the array without a cleanup, since the code
is simple enough that we can make sure it doesn't throw (I was hoping
that eg marking the function noexcept would help guaranty that). But
at the end of the day, although it's manageable in this case, I felt
it was better to go with the safer approach.

Same remark with resizing the array: In practice, we don't need to do
it since we know the bounds and iterate over the elements without
accessing the them from the vector; but it's clearer and safer this way.

> > diff --git a/gdb/configure.tgt b/gdb/configure.tgt
> > index 6d1a4df..a1f703f 100644
> > --- a/gdb/configure.tgt
> > +++ b/gdb/configure.tgt
> > @@ -180,6 +180,7 @@ arm*-*-symbianelf*)
> >  	;;
> >  arm*-*-*)
> >  	# Target: ARM embedded system
> > +        gdb_target_obs="arm-pikeos-tdep.o"
> >  	gdb_sim=../sim/arm/libsim.a
> >  	;;
> 
> The object should be added to ALL_TARGETS_OBS in the Makefile, so it's
> included in an enable-targets=all build.

Argh, yes, true. Added.

> Just to understand better why the object file needs to be added here, what
> is the target triplet? arm-pikeos-something, arm-none-something?

It is arm-*-pikeos*, which config.sub then translates to arm-*-eabi.

> Just wondering: when you connect to the target, you talk to a gdb stub
> that is built right into the application/rtos?

Something like that. We have to use a tool provided by the vendor
called muxa; the tool connects to the system running PikeOS, and
we connect to that tool using the remote protocol.

Thanks for the review!
  

On 2018-09-11 09:56, Joel Brobecker wrote:
>> > +  symbol_table = (asymbol **) xmalloc (storage_needed);
>> > +  make_cleanup (xfree, symbol_table);
>> 
>> It would make Tom really happy if you could avoid introducing a 
>> cleanup :).
>> I would suggest using an std::vector<asymbol *>.  If you'd rather not 
>> do it
>> it's not a big deal, we can change it after.
> 
> Attached is the patch I am testing. I am wondering if this is the best
> way, though. What do you think?

It looks good to me.  You could use a range-for, because it's cool:

   for (asymbol *sym : symbol_table)

but what you have is also fine.

> One question I asked myself is whether we needed the std::vector at
> all, as the building of the vector is a bit clunky in this situation.
> As I understand it, this is mostly to automate the destruction of
> the array. I was wondering whether we could do without the std::vector
> entirely, and just handle the array without a cleanup, since the code
> is simple enough that we can make sure it doesn't throw (I was hoping
> that eg marking the function noexcept would help guaranty that). But
> at the end of the day, although it's manageable in this case, I felt
> it was better to go with the safer approach.

Well, it would be fine to not use a vector, but in any case I would 
recommend the use of an object that ensures the memory is de-allocated 
in any case, whether it is an std::vector, an std::unique_ptr or a 
gdb::unique_xmalloc_ptr.  I don't see any advantage of doing a manual 
free over using one of those.

An alternative would be to use a VLA:

   asymbol *symbol_table[max_number_of_symbols];

which I think ends up being like an alloca.  But in this case there 
could be a huge number of symbols I suppose, so I would avoid that.

> Same remark with resizing the array: In practice, we don't need to do
> it since we know the bounds and iterate over the elements without
> accessing the them from the vector; but it's clearer and safer this 
> way.

Right, with the range-for you would need the resize though.

Simon
  

> > Attached is the patch I am testing. I am wondering if this is the best
> > way, though. What do you think?
> 
> It looks good to me.  You could use a range-for, because it's cool:
> 
>   for (asymbol *sym : symbol_table)
> 
> but what you have is also fine.

Unfortunately, it looks like the change is causing regressions, and
it is a bit obscure at the moment, which is not entirely surprising
when one deals with memory.

> > One question I asked myself is whether we needed the std::vector at
> > all, as the building of the vector is a bit clunky in this situation.
> > As I understand it, this is mostly to automate the destruction of
> > the array. I was wondering whether we could do without the std::vector
> > entirely, and just handle the array without a cleanup, since the code
> > is simple enough that we can make sure it doesn't throw (I was hoping
> > that eg marking the function noexcept would help guaranty that). But
> > at the end of the day, although it's manageable in this case, I felt
> > it was better to go with the safer approach.
> 
> Well, it would be fine to not use a vector, but in any case I would
> recommend the use of an object that ensures the memory is de-allocated in
> any case, whether it is an std::vector, an std::unique_ptr or a
> gdb::unique_xmalloc_ptr.  I don't see any advantage of doing a manual free
> over using one of those.
> 
> An alternative would be to use a VLA:
> 
>   asymbol *symbol_table[max_number_of_symbols];
> 
> which I think ends up being like an alloca.  But in this case there could be
> a huge number of symbols I suppose, so I would avoid that.

Yes, the table might be too large and blow the stack. All things
considered, I think the better model here seems to be to use a
gdb::unique_xmalloc_ptr. I tried that, and the code looks simpler,
but I get the same kind of regressions as above.

And unfortunately at this point, I have to hold off for a while,
because I am out of license, and then I will be traveling home.
But thanks a lot for all the feedback received so far; when I pick
things up again, I will not be starting from scratch.
  

>>>>> "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.

Joel> +  for (i = 0; i < number_of_symbols; i++)

If you have an explicit bound on the loop then you don't need to resize
the vector to be smaller.

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.

Tom