Re: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoidoverriding CONFIG_64BIT

From: David Woodhouse
Date: Sun Jul 31 2011 - 16:52:50 EST


On Sun, 2011-07-31 at 16:24 -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Sun, Jul 31, 2011 at 4:00 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> > On Sun, 2011-07-31 at 15:40 -0400, Arnaud Lacombe wrote:
> >> FWIW, you are still breaking `scripts/checkstack.pl',
> >> `scripts/tags.sh' (all UML related)
> >
> > Can you explain the nature of the breakage? It's probably also easy to
> > fix (or was already arguably broken), but it would be helpful if you'd
> > point at what you think is wrong rather than making me guess.
> >
> scripts/tags.sh:
> [...]
> # Support um (which uses SUBARCH)
> if [ "${ARCH}" = "um" ]; then
> if [ "$SUBARCH" = "i386" ]; then
> archinclude=x86
> elif [ "$SUBARCH" = "x86_64" ]; then
> archinclude=x86
> else
> archinclude=${SUBARCH}
> fi
> fi
>
> So this one is not broken, but the conditionals are deadcode. I wonder
> if it should not just use ${SRCARCH}.

Ah yes, I'd actually looked at that one yesterday since I saw it
referenced from somewhere in the um code that I was looking at. It's not
*quite* deadcode yet â remember, we're not talking about *removing* the
legacy ARCH=i386 and ARCH=x86_64 yet; just making them no longer the
*default*, and making ARCH=x86 the default instead (when on an x86 box).

There are three phases, which we've been through for the various other
architectures that merged 32 and 64 bit code already:

1. Make ARCH=x86 work.
2. Make ARCH=x86 the default.
3. Remove the legacy ARCH= values.

We *thought* we'd fairly much finished #1 in 2007, with commit
208652d6... but evidently there are a couple of things we still need to
fix. As I said, thanks for helping to find those.

My patch is doing #2, since it seems the best and cleanest way to fix
the bug that keeps biting. It's not only "a" fix; it's the *right* thing
to do.

I'm not touching #3 yet; people are still clinging to the old crap as if
the world will end if they have to type 'make CONFIG_64BIT=n oldconfig'
instead of 'make ARCH=i386 oldconfig', because the extra few characters
will give them RSI and then they'll have to quit their nice computer job
and then they'll have to sell their body to make ends meet. Or something
like that. But I'm making the CONFIG_64BIT=n thing work anyway :)



> Makefile:
> ifeq ($(ARCH), um)
> CHECKSTACK_ARCH := $(SUBARCH)
> else
> CHECKSTACK_ARCH := $(ARCH)
> endif
> checkstack:
> $(OBJDUMP) -d vmlinux $$(find . -name '*.ko') | \
> $(PERL) $(src)/scripts/checkstack.pl $(CHECKSTACK_ARCH)
>
> scripts/checkstack.pl:
> my (@stack, $re, $dre, $x, $xs);
> {
> my $arch = shift;
> if ($arch eq "") {
> $arch = `uname -m`;
> chomp($arch);
> }
> [...]
> } elsif ($arch eq 'x86_64') {
> # 2f60: 48 81 ec e8 05 00 00 sub $0x5e8,%rsp
> $re = qr/^.*[as][du][db] \$(0x$x{1,8}),\%rsp$/o;
> $dre = qr/^.*[as][du][db] (\%.*),\%rsp$/o;
>
> this one actually is broken:
>
> % perl scripts/checkstack.pl x86
> wrong or unknown architecture "x86"

OK, I'll go poke at that; it definitely *should* have been working and
could be considered 'broken' since 2007. It's part of phase 1.

This should probably fix it.... I'll test a bit more and send a real
patch. Thanks for pointing it out.

diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl
index 17e3843..2c5c869 100755
--- a/scripts/checkstack.pl
+++ b/scripts/checkstack.pl
@@ -59,6 +59,10 @@ my (@stack, $re, $dre, $x, $xs);
# 2f60: 48 81 ec e8 05 00 00 sub $0x5e8,%rsp
$re = qr/^.*[as][du][db] \$(0x$x{1,8}),\%rsp$/o;
$dre = qr/^.*[as][du][db] (\%.*),\%rsp$/o;
+ } elsif ($arch eq 'x86') {
+ # 2f60: 48 81 ec e8 05 00 00 sub $0x5e8,%rsp
+ $re = qr/^.*[as][du][db] \$(0x$x{1,8}),\%[er]sp$/o;
+ $dre = qr/^.*[as][du][db] (\%.*),\%[er]sp$/o;
} elsif ($arch eq 'ia64') {
#e0000000044011fc: 01 0f fc 8c adds r12=-384,r12
$re = qr/.*adds.*r12=-(([0-9]{2}|[3-9])[0-9]{2}),r12/o;


--
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/