[RFA v2] arm-pikeos: software single step

[Joel Brobecker]

> (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!
-- 
Joel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-arm-pikeos-software-single-step.patch
Type: text/x-diff
Size: 6428 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20180911/52bfcc0c/attachment.bin>