PR4186: cross-compilation, $ARCH

PR4186: cross-compilation, $ARCH

[Frank Ch. Eigler]

Hi -

We need to clear up our use of the generic term "architecture" in
stap, as visible to scripts %( arch %) and the build system (-a foo or
-B ARCH=foo).  The linux kernel has a less fuzzy meaning for it than
we have had, roughly as embodied by the SUBARCH computation in the
top level Makefile:

SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
                                  -e s/arm.*/arm/ -e s/sa110/arm/ \
                                  -e s/s390x/s390/ -e s/parisc64/parisc/ \
                                  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
                                  -e s/sh[234].*/sh/ )


Whereas we in stap land have used uname(2)'s machine, or approximating
"uname -i".  But neither of those matches SUBARCH/ARCH, for cases such
as s390[x], powerpc[64], and others.  The current systemtap git code
breaks on these latter ones.

So, what to do?  A few options:

- Revert some of my cross-arch code, so as to avoid passing ARCH=foo to
  the build system if the user hasn't attempted to override the default.
  This would preserve the inconsistency.  Tapsets would not exist for
  where "uname -m" gives wordy labels like "armv5tejl". 

- Add the same SUBARCH-flattening hack to systemtap, so that we think
  in terms of the same "arch" value as the kernel.  (I don't think
  there exists any kernel API or /proc filesystem that gives us this
  string back at run time!)  So "ppc64" would become plain "powerpc",
  "s390x"->"s390", "arm5tejl"->"arm", and so on.  Tapsets would have
  to be moved around a little more, and third-party scripts that use
  the old %( arch %) names would have to change.

I'm leaning for #2, but I'm looking for more alternatives or advice.

- FChE

Re: PR4186: cross-compilation, $ARCH

[David Smith]

On 08/25/2009 08:33 AM, Frank Ch. Eigler wrote:
> Hi -
> 
> We need to clear up our use of the generic term "architecture" in
> stap, as visible to scripts %( arch %) and the build system (-a foo or
> -B ARCH=foo).  The linux kernel has a less fuzzy meaning for it than
> we have had, roughly as embodied by the SUBARCH computation in the
> top level Makefile:
> 
> SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
>                                   -e s/arm.*/arm/ -e s/sa110/arm/ \
>                                   -e s/s390x/s390/ -e s/parisc64/parisc/ \
>                                   -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
>                                   -e s/sh[234].*/sh/ )
> 
> 
> Whereas we in stap land have used uname(2)'s machine, or approximating
> "uname -i".  But neither of those matches SUBARCH/ARCH, for cases such
> as s390[x], powerpc[64], and others.  The current systemtap git code
> breaks on these latter ones.
> 
> So, what to do?  A few options:
> 
> - Revert some of my cross-arch code, so as to avoid passing ARCH=foo to
>   the build system if the user hasn't attempted to override the default.
>   This would preserve the inconsistency.  Tapsets would not exist for
>   where "uname -m" gives wordy labels like "armv5tejl". 
> 
> - Add the same SUBARCH-flattening hack to systemtap, so that we think
>   in terms of the same "arch" value as the kernel.  (I don't think
>   there exists any kernel API or /proc filesystem that gives us this
>   string back at run time!)  So "ppc64" would become plain "powerpc",
>   "s390x"->"s390", "arm5tejl"->"arm", and so on.  Tapsets would have
>   to be moved around a little more, and third-party scripts that use
>   the old %( arch %) names would have to change.
> 
> I'm leaning for #2, but I'm looking for more alternatives or advice.

I've got a couple of thoughts here:

- Are we planning on extending '%arch' (or perhaps adding '%user_arch')
to tell the difference between 32-bit and 64-bit user exes?

- I'd probably go with solution #2, but also provide "aliases" for the
old names (assuming that's possible).

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: PR4186: cross-compilation, $ARCH

[Frank Ch. Eigler]

Hi -

> [...]
> - Are we planning on extending '%arch' (or perhaps adding '%user_arch')
> to tell the difference between 32-bit and 64-bit user exes?

This would makes sense only as a per-probe-point construct, since the
same stap script on a 64-bit host can instrument 32- and 64-bit
userspace programs just fine.


> - I'd probably go with solution #2 [switching to kernel "arch"], but
> also provide "aliases" for the old names (assuming that's possible).

I don't know.  We'd have to handle things like
  %( arch == "i686" %? /*A*/ %: /*B*/ %) 
and also
  %( arch == "i686" %? /*A*/ %: %( arch == "i386" %? /*B*/ %: /*C*/ %) %)

- FChE

Re: PR4186: cross-compilation, $ARCH

[David Smith]

On 08/25/2009 09:50 AM, Frank Ch. Eigler wrote:
> Hi -
> 
>> [...]
>> - Are we planning on extending '%arch' (or perhaps adding '%user_arch')
>> to tell the difference between 32-bit and 64-bit user exes?
> 
> This would makes sense only as a per-probe-point construct, since the
> same stap script on a 64-bit host can instrument 32- and 64-bit
> userspace programs just fine.
> 
> 
>> - I'd probably go with solution #2 [switching to kernel "arch"], but
>> also provide "aliases" for the old names (assuming that's possible).
> 
> I don't know.  We'd have to handle things like
>   %( arch == "i686" %? /*A*/ %: /*B*/ %) 
> and also
>   %( arch == "i686" %? /*A*/ %: %( arch == "i386" %? /*B*/ %: /*C*/ %) %)
> 
> - FChE

I'm not sure I explained myself well about the aliases (or I didn't read
your response correctly).  What I'm suggesting is that the following
*both* match:

%(arch == "i686" %? /*A*/ %)

%(arch == "i386" %? /*A*/ %)

i.e., in the translator, let arch matching be done with a wildcard.  In
the case of x86, it would be like checking the user's string against the
regular expression 'i[3-6]86'.

I just poked through the tapsets, and it seems that when i386/i686 are
looked at, both cases appear to be handled the same anyway, so it
wouldn't really matter if both matched.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: PR4186: cross-compilation, $ARCH

[Frank Ch. Eigler]

Hi -

On Tue, Aug 25, 2009 at 10:13:15AM -0500, David Smith wrote:
> [...]
> > I don't know.  We'd have to handle things like
> >   %( arch == "i686" %? /*A*/ %: /*B*/ %) 
> > and also
> >   %( arch == "i686" %? /*A*/ %: %( arch == "i386" %? /*B*/ %: /*C*/ %) %)
> > 
> > - FChE
> 
> I'm not sure I explained myself well about the aliases (or I didn't read
> your response correctly).  What I'm suggesting is that the following
> *both* match:
> 
> %(arch == "i686" %? /*A*/ %)
> 
> %(arch == "i386" %? /*A*/ %)
>
> i.e., in the translator, let arch matching be done with a wildcard.  In
> the case of x86, it would be like checking the user's string against the
> regular expression 'i[3-6]86'.

Right, the problem occurs in the "else" case, where some hypothetical
script tested vs. i686 as distinct from i386.

> I just poked through the tapsets, and it seems that when i386/i686
> are looked at, both cases appear to be handled the same anyway, so
> it wouldn't really matter if both matched.

Sure, we can adjust all our script code for consistency.  That leaves
only existing third-party scripts as a possible rationale for backward
compatibility hacks.

- FChE

Re: PR4186: cross-compilation, $ARCH

[Mark Wielaard]

On Tue, 2009-08-25 at 10:50 -0400, Frank Ch. Eigler wrote:
> > [...]
> > - Are we planning on extending '%arch' (or perhaps adding '%user_arch')
> > to tell the difference between 32-bit and 64-bit user exes?
> 
> This would makes sense only as a per-probe-point construct, since the
> same stap script on a 64-bit host can instrument 32- and 64-bit
> userspace programs just fine.

We actually have this BTW. The various tapset/<arch>/register.stp
tapsets define it when appropriate for the arch as:

function probing_32bit_app() %{ /* pure */
        THIS->__retvalue = _stp_probing_32bit_app(CONTEXT->regs);
%}

Where _stp_probing_32bit_app is defined in runtime/regs.c for various
#if defined(ARCH) settings.

(Note that it relies on the probe context having CONTEXT->regs, if not
then it always returns false.)

Cheers,

Mark