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

Timestamp:

03/07/16 05:04:33 (8 years ago)

Author:

Chris Johns

Comment:

Fix link rendering.

Developer/Projects/Open/TraceTool

@@ -61 +61 @@
 This is an opened ended task and not one to be initially focused on but is here for completeness. 
 
-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. 
+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. 
 
 For 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.