Changes between Version 81 and Version 82 of Developer/Projects/Open/TraceTool


Ignore:
Timestamp:
Mar 7, 2016, 5:04:33 AM (4 years ago)
Author:
Chris Johns
Comment:

Fix link rendering.

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Projects/Open/TraceTool

    v81 v82  
    6161This is an opened ended task and not one to be initially focused on but is here for completeness.
    6262
    63 The rtems-tld uses the binutils symbol mapping feature in GNU ld and I have observed some interesting behaviour with it. It would be good to characterise this behaviour and if possible improve the support in GNU ld. I however feel there are limitations, eg tracing static C functions internally optimised by the compiler, C++ and templates, and more. Long term there maybe the need to add passes to gcc to allow even better trace control. I can see us using the [[https://fedorahosted.org/gcc-python-plugin/ GCC Python Plug-In]] tool.
     63The rtems-tld uses the binutils symbol mapping feature in GNU ld and I have observed some interesting behaviour with it. It would be good to characterise this behaviour and if possible improve the support in GNU ld. I however feel there are limitations, eg tracing static C functions internally optimised by the compiler, C++ and templates, and more. Long term there maybe the need to add passes to gcc to allow even better trace control. I can see us using the [https://fedorahosted.org/gcc-python-plugin/ GCC Python Plug-In] tool.
    6464
    6565For this to happen I would like to see a separate GCC Plug-In project within RTEMS for RTEMS started and trace support being just one part of it. This would allow other interesting but yet to be defined things requiring GCC plug-in passes to be collected in one place. A separate project for special gcc passes would allow auditing and controls to be added so those users in our community who need to know everything about the code running in their target can control what happens.