[PATCH] covoar: Fix DWARF reading

Joel Sherrill joel at rtems.org
Sat Mar 13 21:43:20 UTC 2021


On Fri, Mar 12, 2021 at 5:47 PM Chris Johns <chrisj at rtems.org> wrote:

> These are design question and not review issues ....
>
> On 12/3/21 5:33 am, Alex White wrote:
> > +  // Create data based on target.
> > +  TargetInfo = Target::TargetFactory( buildTarget );
>
> Any pointers in this object given there is a copy operator at work here?
>

There shouldn't be.


>
> > +  // Create the set of desired symbols.
> > +  SymbolsToAnalyze = new Coverage::DesiredSymbols();
>
> How hard would it be to convert these types of allocations in covoar to
> std::shared_ptr<> or std::unique_ptr<> (if that is suitable or possible)?
>

We probably need to have a data flow discussion as part of evaluating this.
When (if) this code is parallellized like Alex and I would love to see
done,
the base information gathering will happen upfront and then the analysis
and report generation can happen in separate threads for each symbol
set. This reduces the objdump for sure. I thinkTargetinfo is a shared
read-only
class once created and all threads can share it.

SymbolSet would become a thread local variable since a thread would be
created per SymbolSet.


>
> Chris
> _______________________________________________
> 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/20210313/63b00419/attachment-0001.html>


More information about the devel mailing list