[PATCH] covoar: Fix DWARF reading
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