[PATCH] covoar: Fix DWARF reading

[Chris Johns]

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.

Chris