[PATCH] record: Add wrappers for malloc() functions

[Chris Johns]

On 2/9/19 3:37 pm, Sebastian Huber wrote:
> On 01/09/2019 04:29, Chris Johns wrote:
>> On 30/8/19 11:07 pm, Sebastian Huber wrote:
>>> Introduce new library librtemsrecordwrap.a which contains wrappers for
>>> operating system functions which produce entry/exit events.
>>
>> Why not enhance the trace linker to handle the recorder you have developed? It
>> has been able to wrap malloc and friends for a while now, it is just lacking
>> support for your recent tracing effort.
>>
>> Currently the trace linker does not uses the DWARF information to determine the
>> function signature as the DWARF support was added to the tool kit after it was
>> created and it has not been updated. The idea is to have DWARF provide the
>> signature of any suitable function so it can be wrapped.
> 
> With the DWARF information at hand it should be possible to generate generic
> record events for function calls with up to 10 input arguments
> (RTEMS_RECORD_ARG_[0-9]) and up to 10 return values (RTEMS_RECORD_RETURN_[0-9]).
> We need two events for generic function entry/exit:
> 
> RTEMS_RECORD_FUNCTION_ENTRY
> RTEMS_RECORD_FUNCTION_EXIT
> 
> The event data for these two is the function address.
> 
>>
>> I do not see any upside adding this library or wrapping specific functions
>> this way.
> 
> The benefits are:
> 
> * Slightly more compact (the event indicates the function and the data can be
> used for the caller address instead, the generic function entry/exit needs two
> events for this).

Could you please explain this, sorry I am not sure what this means? If the code
is what needs to be generated then why not generate?

> * It works without extra tools to build the application.

You need a bunch of extra tools to record the data and view it. The trace linker
is built and installed when the tools are built and installed.

> * It can be tested through the RTEMS test suite.

We lack better tests for our external tools and adding this would be good to
have. If you need a way to test the template adding it to a specific test would
work.

> * You don't need the ELF file to produce a report.

I recommend all users archive the ELF image of an executable with full debug
info because you can look into crash dumps. Without it you can only guess.

> The only strong argument is the first one. A future support in the trace linker
> could use the librtemsrecordwrap.a and only generate generic stubs for other
> functions.

It complicates the management of wrapping become you have some functions in a
special library and others being wrapped.

> Adding the DWARF support could be a GSoC 2020 project.

Sure, or it can be added if we have need.

As I said I do not see the value only a convenience for a specific use case for
some work flows. I do see confusion for other users, ie where is a function I
would like to trace. Maybe explaining the performance issue will help.

Chris