Re: Getting the instruction pointer on a per arch basis

[Martin Schwidefsky <schwidefsky@de.ibm.com>]

On Tue, 31 Jul 2018 16:09:06 -0700
Nick Desaulniers <ndesaulniers@google.com> wrote:

> + More maintainers and lists for visibility
> 
> On Tue, Jul 31, 2018 at 3:32 PM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> >
> > I'm currently looking into cleaning up the code duplication between
> > current_text_addr() and _THIS_IP_, virtually every implementation of
> > current_text_addr() and _THIS_IP_ itself are basically:
> >
> > #define _THIS_IP_ ({ __label__ _l; _l: &&_l; })
> >
> > For a few arch's, they have inline assembly instead (for
> > current_text_addr()).  Examples:
> > * s390
> > * sh
> > * ia64
> > * x86 (um and 32b)
> > * c6x
> > * sparc
> >
> > I have a patch that cuts down on the duplication, but I don't
> > understand why the few arch specific implementations are necessary.  I
> > could reduce the duplication further if it's ok to just use the
> > statement expression.
> >
> > Does anyone know why this is the case?

For s390 it is just that we did not know about the label trick when we
introduced the define. The inline has an advantage though, the code
generated with the label trick is using a LARL instruction which is
4 bytes, the inline assembly uses a BASR which is 2 bytes.

If I use the label method in current_text_addr() the size of vmlinux
increases by a small amount:

add/remove: 33/13 grow/shrink: 101/48 up/down: 11941/-8887 (3054)

This is acceptable though, I would not mind if _THIS_IP_ and
current_text_addr use a common definition using labels.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.