[PATCH] covoar: Add option to create named objdumps

Chris Johns chrisj at rtems.org
Mon Mar 29 21:38:51 UTC 2021


On 30/3/21 7:56 am, Gedare Bloom wrote:
> On Fri, Mar 12, 2021 at 10:07 AM Alex White <alex.white at oarcorp.com> wrote:
>>
>> This adds a new behavior to the -d option which allows the creation of
>> named objdump outputs in the /tmp directory. This allows the outputs to
>> be reused on subsequent runs of covoar rather than running objdump
>> again.
> This seems to be a hackish way to optimize a behavior. Do you guys
> have a plan to improve this caching mechanism?

Agreed. If objdump and generated files is being used then caching and management
across instances of covoar will be complex but that is one of the trade-offs
when wrapping objdump.

>> -        throw rld::error( "Objdump error", "generating objdump" );
>> +      if (!debug || FileIsNewer( fileName.c_str(), objdumpFile.name().c_str() )) {
> what's this !debug
> 
> Relying on timestamps can be tricky. You all should consider how to
> create a proper cache of files, probably in the local directory from
> which this tool is run, that updates based on hashed contents of the
> source files rather than timestamps.  This is for your TODO list.

The commit comment says the files are in /tmp. Using /tmp to hold files that are
not temporary seems the contradict the idea of a temporary directory.

Who cleans up the files in /tmp that are left there?

>> +{
>> +  size_t idx = path.rfind('/', path.length());
> Are there any library helpers that can do this?
> 
> What happens if you run this on windows? (I know the answer, this
> stuff doesn't work on windows. But it doesn't mean we shouldn't
> consider cross-platform issues?)

Windows is a supported host for this project so I hope it is tested on Windows.
Not building or not working just means someone else needs to fix the problem.

Chris


More information about the devel mailing list