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).

* It works without extra tools to build the application.

* It can be tested through the RTEMS test suite.

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

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.

Adding the DWARF support could be a GSoC 2020 project.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to