On 02/09/2019 08:00, Chris Johns wrote:
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.
Ok, all extra RTEMS tools are installed via the RSB, so we can drop this
point.
* 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.
Yes, you should archive the ELF file, so we can drop this point.
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.
We have to make a trade-off between
* a slightly more complicated host tool, and
* higher memory demands on the target system.
From my point of view lower memory demands on the target system are
much more attractive.
If we add DWARF support to the RTEMS Trace Linker, then the
configuration interface will drastically change since you no longer need
the bits an pieces to construct the wrapper code. The question is on
which API do we base this on, directly the libdwarf or instead
rld::dwarf::file? To me this looks like a complex multi week project.
Adding pre-defined wrappers for standard functions can be done by a
student if an example is available. They are also highly desirable due
to the more compact format on the target. Also the consumer side is
simplified (just a case in a switch, otherwise you have to go from an
address to a function name to the output handler), e.g. to translate
record items to LTTNG system call events.
I am not sure if the generator definition via configuration files is the
right thing to do. I am more in favour of doing this in C++ via subclasses.
--
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
