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?
--
Thanks,
~Nick Desaulniers
+ More maintainers and lists for visibility
On Tue, Jul 31, 2018 at 3:32 PM Nick Desaulniers
<[email protected]> 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?
> --
> Thanks,
> ~Nick Desaulniers
On 07/31/2018 04:09 PM, Nick Desaulniers wrote:
> + More maintainers and lists for visibility
>
Ideally the [email protected] mailing list would be sufficient,
but I doubt that it is. :(
--
~Randy
On Tue, 31 Jul 2018 16:09:06 -0700
Nick Desaulniers <[email protected]> wrote:
> + More maintainers and lists for visibility
>
> On Tue, Jul 31, 2018 at 3:32 PM Nick Desaulniers
> <[email protected]> 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.
On Tue, Jul 31, 2018 at 10:41 PM Martin Schwidefsky
<[email protected]> wrote:
>
> On Tue, 31 Jul 2018 16:09:06 -0700
> Nick Desaulniers <[email protected]> wrote:
>
> > + More maintainers and lists for visibility
> >
> > On Tue, Jul 31, 2018 at 3:32 PM Nick Desaulniers
> > <[email protected]> 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)
Thanks for the measurements. Was this output produced by a utility?
> This is acceptable though, I would not mind if _THIS_IP_ and
> current_text_addr use a common definition using labels.
Thank you for this feedback Martin, I appreciate it. Patches soon.
--
Thanks,
~Nick Desaulniers
On Wed, 1 Aug 2018 11:21:13 -0700
Nick Desaulniers <[email protected]> wrote:
> On Tue, Jul 31, 2018 at 10:41 PM Martin Schwidefsky
> <[email protected]> wrote:
> >
> > On Tue, 31 Jul 2018 16:09:06 -0700
> > Nick Desaulniers <[email protected]> wrote:
> >
> > > + More maintainers and lists for visibility
> > >
> > > On Tue, Jul 31, 2018 at 3:32 PM Nick Desaulniers
> > > <[email protected]> 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)
>
> Thanks for the measurements. Was this output produced by a utility?
Yes, ./scripts/bloat-o-meter
> > This is acceptable though, I would not mind if _THIS_IP_ and
> > current_text_addr use a common definition using labels.
>
> Thank you for this feedback Martin, I appreciate it. Patches soon.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.