student for gsoc2008

[Chris Johns]

Reng Zeng wrote:
> Thanks Chris, your reply helps a lot on my proposal draft. I am writing 
> down my understanding inline marked [Alan] to confirm with you.
> 
> Regards,
> Alan
> 
> 2008/3/26, Chris Johns <chrisj at rtems.org <mailto:chrisj at rtems.org>>:
> 
> 
>     Yes this is correct. We need to flatten the argument list to a block
>     of memory
>     to capture. The wrapper code generator will know all the details of the
>     function's signature so can determine the amount of stack used to hold
>     arguments. The variable argument functions such as printf are
>     something I am
>     yet to figure out. This is part of the work.
> 
> 
> [Alan] I think it can determine the amount of stack required ONLY if we 
> make the generator running together with the RTEMS to generate wrapper 
> code, otherwise, the function signature itself can not figure out the 
> required memory.

I have Python code that you run on the host that extracts the signature and 
all types etc from an object file or library. It uses the readelf and objdump 
(-e option) to obtain the debug information in a ctags format. It then 
recreates the function signature held in the library or object file. This 
approach does not reply on parsing header files (with macros) or us needing to 
keep local signatures in sync with code. I seem to remember the data we get 
from this tool includes sizes so we should be able to determine the amount of 
stack used by arguments.

> 
> I guess most of the functions are not variable argument one. For 
> variable one like printf, we could wrap as well as below, but I do not 
> figure out how the wrapper code generator could generate it :)
> 
> #include <stdio.h>
> #include <stdarg.h>
> 
> int __wrap_printf(const char *template, ...)
> {
>     int iRet;
>     va_list argp;
>     va_start(argp, template);
>     iRet = vprintf(template, argp);
>     va_end(argp);
>     return iRet;
> }
>  

This is ok for this function because we have the vprintf function, how-ever we 
can be sure this is always the case.

> 
>     The capture engine's role changes a little when logging wrapped
>     calls. When in
>     the context switch path performance is key while in the wrapped mode the
>     overhead of the block copy of arguments is something we know has to
>     happen and
>     have to factor in.
> 
>     The example code above it is close. We need to decide if we log only
>     once when
>     we have the return value with 2 time stamps (entry/exit). This
>     lowers the
>     overheads down but complicates the data stream on the host side as
>     nested
>     traced calls will appear before the current call.
> 
> 
> [Alan] I understand what you are talking about is, whether to log during 
> both entry and exit, or to log during one of them only. Right? If so, 
> that could be part of work to decide the option.
> 

I think Joel's example has decided this.

>      > I believe Chris has an idea where the trigger is actually in the
>     capture
>      > engine and users can provide boolean expressions.  Greatly simplifies
>      > the logging.
> 
> 
>     We need generate some sort of id which is specific to a function's
>     signature
>     and then have a way to match this with the running target image and
>     finally
>     the resulting data. Once we have this the capture engine can handle the
>     trigger and filter processing keeping this code in one place.
> 
>     We may have the tool generate code that is compiled into the
>     application to
>     handle static filters and triggers rather than a user interface.
>     This code is
>     just making calls to the capture engine.
> 
> 
> [Alan] I understand the "static" here means, instead dynamically setting 
> the trigger/filter during run-time, statically have the trigger/filter 
> written into the code as pre-defined trigger/filter so that once trace 
> is enabled, the static trigger/filter is enabled.
> 

Yes. Some users have an analysis requirement and so want to have static 
configurations that do not change and start automatically. Other users need a 
tool to debug an application and need dynamic control.

>     Let me explain. We could have a target that is connected to via TCP.
>     The user
>     has wrapped a list of functions then interacts with the running
>     target to set
>     filters and triggers dynamically in a series of runs to isolate a
>     bug. The
>     second example is a system where the list of wrapped functions is
>     generated
>     from the static filter and trigger commands which are also turned
>     into target
>     code run during initialisation. Both systems use the same capture
>     engine code.
> 
> 
>      > Plus with the wrapping idea, you turn the wrapper completely off via
>      > ld arguments.  That part can be done manually or via a GUI to
>     generate
>      > a file that is passed to the ld command line.
> 
> 
>     This is something we need to figure out. For example do I build my RTEMS
>     application as I do then say capture tool relink to be a traceable
>     executable
>     or do users application build systems need to know what to do. The
>     issue here
>     is how we manage or help the user with the build process when wrapping.
> 
> 
> [Alan] Are we going to  build the wrapper code into the RTEMS if the 
> performance impact is acceptable? If so, why it is required for user 
> application to know how to build the wrapper code in?

We have a requirement to take a built application and provide analysis of the 
application without changing the code under test. We can relink the 
application and add wrappers as something has to change to allow tracing of 
this type.

The code in the capture engine to support wrapped tracing will be built into 
the RTEMS libraries and linked in when the user decides. I did not think RTEMS 
would be wrapped by default and controlled in real-time.

> 
>      >> 2. Triggers are to be managed by the event ID.
> 
> 
>     I call "event ID" trace points. We can have system trace points like we
>     currently have in the capture enigine, function trace points (wrapped
>     functions) and user trace points where a user makes an explicit call.
> 
> 
> [Alan] about the user trace points here, do you mean user application 
> could make an explicit call to capture engine in their application?
> 

Yes we should allow this. I see a trace point's id having a class plus other 
fields. A class of trace points could be APPLICATION. The user could then 
place in code:

  rtems_capture_app_trace_point (MY_SPECIAL_NUMBER);

We should allow a few of these types of functions that lets the user log 
specific data.


> [Alan] Yes, we should pass all the info host required to decode. Thanks 
> again for your detailed explanation!

No problem. Sorry I was off the air for a while.

Regards
Chris