On 14/3/21 8:43 am, Joel Sherrill wrote: > On Fri, Mar 12, 2021 at 5:47 PM Chris Johns <chr...@rtems.org > <mailto:chr...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
