An introduction to creating GCC plugins
An introduction to creating GCC plugins
Posted Sep 29, 2011 21:58 UTC (Thu) by PaXTeam (guest, #24616)Parent article: An introduction to creating GCC plugins
Posted Sep 30, 2011 13:38 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
I'd vote for a way to point out such oportunities to hackers, or even write source patches. Some magic mangling that gives object code that doesn't behave as the source says is deeply disturbing to my little mind.
Posted Sep 30, 2011 21:10 UTC (Fri)
by PaXTeam (guest, #24616)
[Link]
to give you some numbers, an allmodconfig 2.6.39 i386 kernel loses over 7000 static (i.e., not runtime allocated) writable function pointers (a reduction of about 16%). creating an equivalent source patch would be thousands of lines of code and have virtually no chance to be accepted in any reasonable amount of time (not to mention the maintenance effort of being out-of-tree during the process; i've carried a small fraction of such a patch in PaX for years and it was a PITA even if the patch itself was 'only' 800k).
also by virtue of enforcing const on these types one will quickly find out all the places where variables of a given type are modified (sometimes in direct contradiction to kernel policy) and one will be forced to document it in the code (for each such exception there's a writable type to be used, based on the no_const attribute introduced by the plugin). the patch for this is about 100k, but it also includes changes that actually eliminate the need to modify a given variable (vs. just changing its type to be writable).
all in all, the cost/benefit ratio of the plugin approach is excellent and there's a lot more in the pipeline ;).
Posted Oct 4, 2011 8:44 UTC (Tue)
by MattDavis (guest, #79566)
[Link]
An introduction to creating GCC plugins
An introduction to creating GCC plugins
An introduction to creating GCC plugins