On Tue, 2012-10-30 at 15:35 +0000, Will Newton wrote: > On Tue, Oct 30, 2012 at 3:05 PM, Steven Rostedt <[email protected]> wrote: > > On Tue, 2012-10-30 at 14:51 +0000, Will Newton wrote: > >> Scan any text section whose name begins with ".text." so > >> we will find all the functions in a kernel built with > >> -ffunction-sections. > > > > A couple of things. > > > > First, I'm very paranoid about a blanket "ok" on sections. We must > > guarantee that all sections that starts with ".text" never is freed. And > > if it is freed, that it must inform ftrace that it's about to free it > > before it does. If we can not guarantee this, then we can't do it. > > I share that concern, however it looks like it should be safe.
Can we confirm that it is safe. I'm not too confident with the words "looks like" ;-) > The two > architectures in tree that enable -ffunction-sections by default are > parisc and score and they both use a .text.* wildcard in their linker > script. If the support for building with --gc-sections is ever > completed then that would require -ffunction-sections and a similar > wildcard to be applied to section names. We need to make a way to guarantee any section that is added as ".text" is never removed (freed), except for modules, which already have a way to notify ftrace that its removing its text. > > > Second, most archs today do not use recordmcount.pl. They use the new > > recordmcount.c file. > > Ok, thanks for letting me know. Is the plan to switch over to > recordmcount.c exclusively at some point? When all the archs convert. > > The following architectures have some support in recordmcount.c but do > not enable it: > > sh, powerpc, ia64 Hmm, I have a powerpc, I should get that fixed. > > And the following have no support in recordmcount.c as yet: > > blackfin, microblaze It's up to the arch maintainers to do the work. If the perl script is good enough for them then I have no problem maintaining both. But I don't have the machines to test these archs. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
