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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
