* PR4186: cross-compilation, $ARCH
@ 2009-08-25 13:54 Frank Ch. Eigler
2009-08-25 14:42 ` David Smith
0 siblings, 1 reply; 6+ messages in thread
From: Frank Ch. Eigler @ 2009-08-25 13:54 UTC (permalink / raw)
To: systemtap
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR4186: cross-compilation, $ARCH
2009-08-25 13:54 PR4186: cross-compilation, $ARCH Frank Ch. Eigler
@ 2009-08-25 14:42 ` David Smith
2009-08-25 14:50 ` Frank Ch. Eigler
0 siblings, 1 reply; 6+ messages in thread
From: David Smith @ 2009-08-25 14:42 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: systemtap
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR4186: cross-compilation, $ARCH
2009-08-25 14:42 ` David Smith
@ 2009-08-25 14:50 ` Frank Ch. Eigler
2009-08-25 15:13 ` David Smith
2009-08-27 20:28 ` Mark Wielaard
0 siblings, 2 replies; 6+ messages in thread
From: Frank Ch. Eigler @ 2009-08-25 14:50 UTC (permalink / raw)
To: David Smith; +Cc: systemtap
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR4186: cross-compilation, $ARCH
2009-08-25 14:50 ` Frank Ch. Eigler
@ 2009-08-25 15:13 ` David Smith
2009-08-25 15:15 ` Frank Ch. Eigler
2009-08-27 20:28 ` Mark Wielaard
1 sibling, 1 reply; 6+ messages in thread
From: David Smith @ 2009-08-25 15:13 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: systemtap
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR4186: cross-compilation, $ARCH
2009-08-25 15:13 ` David Smith
@ 2009-08-25 15:15 ` Frank Ch. Eigler
0 siblings, 0 replies; 6+ messages in thread
From: Frank Ch. Eigler @ 2009-08-25 15:15 UTC (permalink / raw)
To: David Smith; +Cc: systemtap
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR4186: cross-compilation, $ARCH
2009-08-25 14:50 ` Frank Ch. Eigler
2009-08-25 15:13 ` David Smith
@ 2009-08-27 20:28 ` Mark Wielaard
1 sibling, 0 replies; 6+ messages in thread
From: Mark Wielaard @ 2009-08-27 20:28 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: David Smith, systemtap
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-08-27 20:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-25 13:54 PR4186: cross-compilation, $ARCH Frank Ch. Eigler
2009-08-25 14:42 ` David Smith
2009-08-25 14:50 ` Frank Ch. Eigler
2009-08-25 15:13 ` David Smith
2009-08-25 15:15 ` Frank Ch. Eigler
2009-08-27 20:28 ` Mark Wielaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).