* Josh Poimboeuf <jpoim...@redhat.com> wrote:
> On Sat, Jul 18, 2015 at 04:51:16AM +0200, Ingo Molnar wrote:
> > Note what the names _don't_ contain: that we generate debug info! That fact
> > is not
> > present in the naming, and that's very much intentional, because the
> > precise form
> > of debug info is conditional:
> >
> > - if CONFIG_FRAME_POINTERS=y then we push/pop a stack frame
> >
> > - if (later on) we do CFI annotations we don't push/pop a stack frame but
> > emit
> > CFI debuginfo
>
> According to current plan, the macro won't add CFI annotations. That will be
> done instead by a separate tool. So the macro really is frame pointer
> specific.
Still the same argument applies: it's a debug info detail we should hide as
much
as sensibly possible. In the CONFIG_FRAME_POINTERS=y case it will be code, in
the
future !CONFIG_FRAME_POINTERS case it will be nothing.
> > In that sense 'FRAME' should never be in these names I think, nor 'PROC'
> > (which is not symmetric).
> >
> > Plus all 3 variants I suggested are very easy to remember, why I'd always
> > have
> > to look up any non-symmetric macro name called 'PROC'...
>
> The reason I suggested to put FRAME in the macro name is to try to prevent it
> from being accidentally used for leaf functions, where it isn't needed.
Well, we could use LEAF_FUNCTION to mark that fact.
Wether a function written in assembly is a leaf function or not is a higher
level
(and thus more valuable) piece of information whether we generate frame pointer
debuginfo or not.
> Also the naming of FUNCTION_ENTRY and FUNCTION_RETURN doesn't do anything to
> distinguish them from the already ubiquitous ENTRY and ENDPROC. So as a
> kernel
> developer it seems confusing to me, e.g. how do I remember when to use
> FUNCTION_ENTRY vs ENTRY?
'ENDPROC' is really leftover from older debuginfo cruft, it's not a valuable
construct IMHO, even if it's (sadly) ubiquitious.
We want to create new, clean, as minimal as possible and as clearly named as
possible debuginfo constructs from first principles.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
