On Thu, Jan 28, 2016 at 03:26:59PM +1100, Michael Ellerman wrote:
>
> That raises an interesting question, how does it work *without*
> DYNAMIC_FTRACE?
>
> It looks like you haven't updated that version of _mcount at all? Or maybe I'm
> missing an #ifdef somewhere?
You didn't, I did. I haven't considered that combination.
> It doesn't look like that will work right with the -mprofile-kernel ABI. And
> indeed it doesn't boot.
The lean _mcount should handle it and boot, had I not misplaced it in
the #ifdefs, but then of course profiling wouldn't work.
> So we'll need to work that out. I guess the minimum would be to disable
> -mprofile-kernel if DYNAMIC_FTRACE is disabled.
I feel that supporting all combinations of ABIv1/ABIv2, FTRACE/DYNAMIC_FTRACE,
-p/-mprofile-kernel will get us into #ifdef hell, and at least one kernel
developer will go insane. That will probably be the one porting this
to ppc64be (ABIv1).
> Frankly I think we'd be happy to *only* support DYNAMIC_FTRACE, but the
> generic
> code doesn't let us do that at the moment.
Seconded.
I'll have a look at the Kconfigs.
> But it's better than the previous version which didn't boot :)
That's your fault, you picked the wrong compiler ;-)
> Also ftracetest fails at step 8:
> ...
> [8] ftrace - function graph filters with stack tracer
> Unable to handle kernel paging request for data at address
> 0xd0000000033d7f70
[...]
> That doesn't happen without your series applied, though that doesn't 100% mean
> it's your bug. I haven't had time to dig any deeper.
Will check as well...
Torsten
