Re: [PATCH] record: Add wrappers for malloc() functions
On 6/9/19 11:09 pm, Sebastian Huber wrote: > 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. Yes I agree, there is no issue with the code itself, it is about the location of the code, why we have chosen that path, and possible issues further in time when we may want to change the implementation. I would like to examine the use cases... 1. I see the most common use case is connecting to a system to gather interrupt and task context switching details. The user starts a service however no handlers are installed until a connection is made to trace. 2. A variation of this is a system with a runtime system configuration option (eg boot option) to enable the tracing service. By default it is disabled. This is a system integration function where something during integration is not working and needs investigation by an engineering team. Rebuilding code and loading it onto a system may not be easy or possible and staring at the system offers no insight. 3. Development profiling, validation or debugging of specific pieces of code. This is a special link to wrap and trace specific code. The wrapping is unconditional and a development tool for development builds of an application. 4. Instrumentation of specific pieces of code where wrapping is not possible. There are specific cases where wrapping is problematic and insertion of trace code is needed to instrument it. As you move from use case 1 to 4 a more detail knowledge of how trace works is needed. I see for 1. you make a call to register a service and that enables a transport, eg bind to a socket and listen. I would expect the various tools in rtems-tool to work from the command with no configurations, changes or rebuilds. Use case 2. is similar to 1. but the target trace code is resident but dormant until needed. The key point is the target trace hooks are dynamic and not configuration tabl
Re: [PATCH] record: Add wrappers for malloc() functions
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
Re: [PATCH] record: Add wrappers for malloc() functions
On 02/09/2019 09:00, Chris Johns wrote: Why not generate the call to `rtems_record_produce_2`? You should be able to determine this give you will know there in a single item plus the return address to record. In fact there is little need for `rtems_record_produce_n` if you have [1..n] already defined. The rtems_record_produce_2() is just an optimization since most architectures accept up to four arguments via registers. The particular rtems_record_produce*() function is not the issue here. -- 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
Re: [PATCH] record: Add wrappers for malloc() functions
On 2/9/19 4:11 pm, Sebastian Huber wrote:
> On 02/09/2019 08:00, Chris Johns wrote:
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?
>
> The record items is defined like this:
>
> /**
> * @brief The record data integer type.
> *
> * It is big enough to store 32-bit integers and pointers.
> */
> typedef unsigned long rtems_record_data;
>
> /**
> * @brief The native record item.
> */
> typedef struct __attribute__((__packed__)) {
> uint32_t event;
> rtems_record_data data;
> } rtems_record_item;
>
> The event member contains a 22-bit time stamp and a 10-bit event number.
>
> The malloc entry/exit wrapper with a special event number looks like this:
>
> void *__wrap_malloc( size_t size )
> {
> void *ptr;
>
> rtems_record_produce_2(
> RTEMS_RECORD_MALLOC_ENTRY,
> (rtems_record_data) RTEMS_RETURN_ADDRESS(),
> RTEMS_RECORD_ARG_0,
> size
> )
> ptr = __real_malloc( size );
> rtems_record_produce_2(
> RTEMS_RECORD_MALLOC_EXIT,
> (rtems_record_data) RTEMS_RETURN_ADDRESS(),
> RTEMS_RECORD_RETURN_0,
> (rtems_record_data) ptr
> )
> return ptr;
> }
>
> If you have to encode the function in the event data, then you need two extra
> items:
>
> void *__wrap_malloc( size_t size )
> {
> rtems_record_item items[ 3 ];
> void *ptr;
>
> items[ 0 ].event = RTEMS_RECORD_FUNCTION_ENTRY;
> items[ 1 ].data = (rtems_record_data) __real_malloc;
> items[ 1 ].event = RTEMS_RECORD_CALLER;
> items[ 1 ].data = (rtems_record_data) RTEMS_RETURN_ADDRESS();
> items[ 2 ].event = RTEMS_RECORD_ARG_0;
> items[ 2 ].data = size;
> rtems_record_produce_n( items, RTEMS_ARRAY_SIZE( items ) );
> ptr = __real_malloc( size );
> items[ 0 ].event = RTEMS_RECORD_FUNCTION_EXIT;
> items[ 1 ].data = (rtems_record_data) __real_malloc;
> items[ 1 ].event = RTEMS_RECORD_CALLER;
> items[ 1 ].data = (rtems_record_data) RTEMS_RETURN_ADDRESS();
> items[ 2 ].event = RTEMS_RECORD_RETURN_0;
> items[ 2 ].data = (rtems_record_data) ptr;
> rtems_record_produce_n( items, RTEMS_ARRAY_SIZE( items ) );
> return ptr;
> }
>
> For this simple one argument function, this is a 50% increase.
>
Why not generate the call to `rtems_record_produce_2`? You should be able to
determine this give you will know there in a single item plus the return address
to record. In fact there is little need for `rtems_record_produce_n` if you have
[1..n] already defined.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] record: Add wrappers for malloc() functions
On 02/09/2019 08:00, Chris Johns wrote:
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?
The record items is defined like this:
/**
* @brief The record data integer type.
*
* It is big enough to store 32-bit integers and pointers.
*/
typedef unsigned long rtems_record_data;
/**
* @brief The native record item.
*/
typedef struct __attribute__((__packed__)) {
uint32_t event;
rtems_record_data data;
} rtems_record_item;
The event member contains a 22-bit time stamp and a 10-bit event number.
The malloc entry/exit wrapper with a special event number looks like this:
void *__wrap_malloc( size_t size )
{
void *ptr;
rtems_record_produce_2(
RTEMS_RECORD_MALLOC_ENTRY,
(rtems_record_data) RTEMS_RETURN_ADDRESS(),
RTEMS_RECORD_ARG_0,
size
)
ptr = __real_malloc( size );
rtems_record_produce_2(
RTEMS_RECORD_MALLOC_EXIT,
(rtems_record_data) RTEMS_RETURN_ADDRESS(),
RTEMS_RECORD_RETURN_0,
(rtems_record_data) ptr
)
return ptr;
}
If you have to encode the function in the event data, then you need two
extra items:
void *__wrap_malloc( size_t size )
{
rtems_record_item items[ 3 ];
void *ptr;
items[ 0 ].event = RTEMS_RECORD_FUNCTION_ENTRY;
items[ 1 ].data = (rtems_record_data) __real_malloc;
items[ 1 ].event = RTEMS_RECORD_CALLER;
items[ 1 ].data = (rtems_record_data) RTEMS_RETURN_ADDRESS();
items[ 2 ].event = RTEMS_RECORD_ARG_0;
items[ 2 ].data = size;
rtems_record_produce_n( items, RTEMS_ARRAY_SIZE( items ) );
ptr = __real_malloc( size );
items[ 0 ].event = RTEMS_RECORD_FUNCTION_EXIT;
items[ 1 ].data = (rtems_record_data) __real_malloc;
items[ 1 ].event = RTEMS_RECORD_CALLER;
items[ 1 ].data = (rtems_record_data) RTEMS_RETURN_ADDRESS();
items[ 2 ].event = RTEMS_RECORD_RETURN_0;
items[ 2 ].data = (rtems_record_data) ptr;
rtems_record_produce_n( items, RTEMS_ARRAY_SIZE( items ) );
return ptr;
}
For this simple one argument function, this is a 50% increase.
--
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
Re: [PATCH] record: Add wrappers for malloc() functions
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
Re: [PATCH] record: Add wrappers for malloc() functions
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
Re: [PATCH] record: Add wrappers for malloc() functions
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. I do not see any upside adding this library or wrapping specific functions this way. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] record: Add wrappers for malloc() functions
Introduce new library librtemsrecordwrap.a which contains wrappers for
operating system functions which produce entry/exit events.
The wrappers can be selected during link time via the GNU ld --wrap
option.
Update #3665.
---
cpukit/Makefile.am | 5 +
cpukit/libtrace/record/record-wrap-malloc.c | 145 ++
testsuites/libtests/Makefile.am | 8 +
testsuites/libtests/record02/init.c | 23 +-
testsuites/libtests/record02/record02.scn | 691 +++-
5 files changed, 642 insertions(+), 230 deletions(-)
create mode 100644 cpukit/libtrace/record/record-wrap-malloc.c
diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 01ee40980f..3914b3d363 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -1831,6 +1831,11 @@ project_lib_LIBRARIES += librtemsdefaultconfig.a
librtemsdefaultconfig_a_SOURCES =
librtemsdefaultconfig_a_SOURCES += libmisc/dummy/default-configuration.c
+project_lib_LIBRARIES += librtemsrecordwrap.a
+
+librtemsrecordwrap_a_SOURCES =
+librtemsrecordwrap_a_SOURCES += libtrace/record/record-wrap-malloc.c
+
project_lib_LIBRARIES += librtemstest.a
librtemstest_a_SOURCES =
diff --git a/cpukit/libtrace/record/record-wrap-malloc.c
b/cpukit/libtrace/record/record-wrap-malloc.c
new file mode 100644
index 00..2ec3e9c023
--- /dev/null
+++ b/cpukit/libtrace/record/record-wrap-malloc.c
@@ -0,0 +1,145 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2018, 2019 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#if HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include
+
+#include
+
+typedef void *Record_Aligned_alloc(size_t, size_t);
+
+Record_Aligned_alloc aligned_alloc;
+Record_Aligned_alloc __real_aligned_alloc;
+Record_Aligned_alloc __wrap_aligned_alloc;
+
+void *__wrap_aligned_alloc( size_t alignment, size_t size )
+{
+ void *ptr;
+
+ rtems_record_entry_2(
+RTEMS_RECORD_ALIGNED_ALLOC_ENTRY,
+alignment,
+size
+ );
+ ptr = __real_aligned_alloc( alignment, size );
+ rtems_record_exit_1(
+RTEMS_RECORD_ALIGNED_ALLOC_EXIT,
+(rtems_record_data) ptr
+ );
+ return ptr;
+}
+
+typedef void *Record_Calloc( size_t, size_t );
+
+Record_Calloc calloc;
+Record_Calloc __real_calloc;
+Record_Calloc __wrap_calloc;
+
+void *__wrap_calloc( size_t nelem, size_t elsize )
+{
+ void *ptr;
+
+ rtems_record_entry_2( RTEMS_RECORD_CALLOC_ENTRY, nelem, elsize );
+ ptr = __real_calloc( nelem, elsize );
+ rtems_record_exit_1( RTEMS_RECORD_CALLOC_EXIT, (rtems_record_data) ptr );
+ return ptr;
+}
+
+typedef void *Record_Malloc( size_t );
+
+Record_Malloc malloc;
+Record_Malloc __real_malloc;
+Record_Malloc __wrap_malloc;
+
+void *__wrap_malloc( size_t size )
+{
+ void *ptr;
+
+ rtems_record_entry_1( RTEMS_RECORD_MALLOC_ENTRY, size );
+ ptr = __real_malloc( size );
+ rtems_record_exit_1( RTEMS_RECORD_MALLOC_EXIT, (rtems_record_data) ptr );
+ return ptr;
+}
+
+typedef void Record_Free( void *ptr );
+
+Record_Free free;
+Record_Free __real_free;
+Record_Free __wrap_free;
+
+void __wrap_free( void *ptr )
+{
+ rtems_record_entry_1( RTEMS_RECORD_FREE_ENTRY, (rtems_record_data) ptr );
+ __real_free( ptr );
+ rtems_record_entry( RTEMS_RECORD_FREE_EXIT );
+}
+
+typedef int Record_POSIX_memalign( void **, size_t, size_t );
+
+Record_POSIX_memalign posix_memalign;
+Record_POSIX_memalign __real_posix_memalign;
+Record_POSIX_memalign __wrap_posix_memalign;
+
+int __wrap_posix_memalign( void **memptr, size_t alignment, size_t size )
+{
+ int eno;
+
+ rtems_record_entry_3(
+RTEMS_RECORD_POSIX_MEMALIGN_ENTRY,
+(rtems_record_data) memptr,
+alignment,
+size
+ );
+ eno = __real_posix_memalign( mem
