[PATCH 1/2] covoar/ObjdumpProcessor.cc: Add processing for ... padding notation w/hack

Joel Sherrill joel at rtems.org
Thu May 24 13:05:03 UTC 2018


On Thu, May 24, 2018, 7:59 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Wed, May 23, 2018 at 11:11 PM, Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> > On Wed, May 23, 2018, 9:59 PM Chris Johns <chrisj at rtems.org> wrote:
> >>
> >> On 24/5/18 12:07 pm, Joel Sherrill wrote:
> >> > ---
> >> >  tester/covoar/ObjdumpProcessor.cc | 22 ++++++++++++++++++++++
> >> >  1 file changed, 22 insertions(+)
> >> >
> >> > diff --git a/tester/covoar/ObjdumpProcessor.cc
> >> > b/tester/covoar/ObjdumpProcessor.cc
> >> > index d41906c..183722b 100644
> >> > --- a/tester/covoar/ObjdumpProcessor.cc
> >> > +++ b/tester/covoar/ObjdumpProcessor.cc
> >> > @@ -384,6 +384,28 @@ namespace Coverage {
> >> >          break;
> >> >        }
> >> >
> >> > +      // This string indicates a block of padding at the end of a
> >> > method
> >> > +      if (!strncmp(line.c_str(), "\t...", 4)) {
> >>
> >> You have an std::string so why no use C++ rather than resorting to C?
> >>
> >> For example
> http://en.cppreference.com/w/cpp/string/basic_string/compare.
> >
> >
> > I was in a hurry and had trouble getting this logic to trip at all. I
> still
> > fix this. It does need to be like strncmp.
> >
> > The +4 is awful though
> Classical technical debt. :)
>

I hoped Chris could get the info from the dwarf but he has a similar issue.
You see the padding between methods both ways.

When objdump printed a series of nope as padding, I could take the address
of the first nop. With ... there is no address and it is harder to figure
out.

I think dwarf+embedding our own dump library is the long term replacement
so this will keep us moving.

Worst case, I could add code to the target specific code to recognize the
previous instruction and get the size. Hmm.. should be a return variant.
Let me think on that. Can't be that many instructions that make sense as
the last one it a method.

>
> >>
> >>
> >> Chris
> >> _______________________________________________
> >> devel mailing list
> >> devel at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180524/c7c61d22/attachment-0002.html>


More information about the devel mailing list