[PATCH] covoar: Fix DWARF reading

Chris Johns chrisj at rtems.org
Sun Mar 14 01:00:51 UTC 2021

On 14/3/21 8:43 am, Joel Sherrill wrote:
> On Fri, Mar 12, 2021 at 5:47 PM Chris Johns <chrisj at rtems.org
> <mailto: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.

Sure happy too, but I currently only considering the code in front of me.

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

I am wondering about using references or shared pointers and not using any
pointers to objects. This is not related to const or read only attributes.

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

I would discourage TLS and do not support using it in this case. If you add
threading you can support thread bodies as methods of instances of a class and
that is a better model than TLS.


More information about the devel mailing list