Bug#397139: ftbfs alpha + ia64
* Steve Langasek [EMAIL PROTECTED] [2006-11-07 02:37]: And here is the patch which adds explicit .arch specifiers to the inline assembly. I'll commit this to the kernel svn repo shortly. Did you forward this patch upstream? Richard Henderson is very active again, so now would be a great time to propose this patch or ask Richard to implement an alternative patch. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
On Tue, 7 Nov 2006, Falk Hueffner wrote: Steve Langasek [EMAIL PROTECTED] writes: Given that you mention you're not running a Debian kernel at all right now, and that this code is in place upstream and nobody else seems to have complained loudly enough to get it fixed, I'm not sure how much effort we'll want to put into it if it turns out to not work on ev5, but it will still be good to know -- and if the kernel *does* work for you, that's a good reason to find a solution other than switching the kernel to build ev56 code. :) It should work, the code is guarded to be only executed on ev56+. See also the thread http://gcc.gnu.org/ml/gcc/2005-07/msg00371.html Yes, it does seem to work. I'm running linux-image-2.6.18-1-alpha-generic now, and haven't seen anything blatantly broken. Ivan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
On Mon, Nov 06, 2006 at 11:37:23PM -0800, Steve Langasek wrote:
It gets better -- after fixing up the first bit of assembly in the source,
I've found that there's also embedded assembly in sys_titan.c which is
specific to ev6. So even emitting .arch ev56 is going to give a build
failure.
Which convinces me even more that the right answer is to fix the kernel
instead of disabling gcc's ability to sanity-check the insns used.
Patch available as soon as I get to the end of the build.
And here is the patch which adds explicit .arch specifiers to the inline
assembly. I'll commit this to the kernel svn repo shortly.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--- source/include/asm-alpha/compiler.h.orig2006-09-19 20:42:06.0
-0700
+++ source/include/asm-alpha/compiler.h 2006-11-06 17:10:00.0 -0800
@@ -78,16 +78,20 @@
#else
#define __kernel_ldbu(mem) \
({ unsigned char __kir; \
- __asm__(ldbu %0,%1 : =r(__kir) : m(mem)); \
+ __asm__(.arch ev56; \
+ ldbu %0,%1 : =r(__kir) : m(mem));\
__kir; })
#define __kernel_ldwu(mem) \
({ unsigned short __kir; \
- __asm__(ldwu %0,%1 : =r(__kir) : m(mem)); \
+ __asm__(.arch ev56; \
+ ldwu %0,%1 : =r(__kir) : m(mem));\
__kir; })
-#define __kernel_stb(val,mem) \
- __asm__(stb %1,%0 : =m(mem) : r(val))
-#define __kernel_stw(val,mem) \
- __asm__(stw %1,%0 : =m(mem) : r(val))
+#define __kernel_stb(val,mem) \
+ __asm__(.arch ev56; \
+ stb %1,%0 : =m(mem) : r(val))
+#define __kernel_stw(val,mem) \
+ __asm__(.arch ev56; \
+ stw %1,%0 : =m(mem) : r(val))
#endif
#ifdef __KERNEL__
--- source/arch/alpha/kernel/sys_titan.c.orig 2006-11-06 23:17:50.0
-0800
+++ source/arch/alpha/kernel/sys_titan.c2006-11-06 23:17:04.0
-0800
@@ -257,7 +257,7 @@
*/
while (mask) {
/* convert to SRM vector... priority is 63 - 0 */
- __asm__(ctlz %1, %0 : =r(vector) : r(mask));
+ __asm__(.arch ev6; ctlz %1, %0 : =r(vector) : r(mask));
vector = 63 - vector;
mask = ~(1UL vector); /* clear it out */
vector = 0x900 + (vector 4); /* convert to SRM vector */
Bug#397139: ftbfs alpha + ia64
On Sun, Nov 05, 2006 at 01:56:28PM +0100, maximilian attems wrote: -- snipp ia64 CC mm/hugetlb.o mm/hugetlb.c: In function 'copy_huge_page': mm/hugetlb.c:54: error: too few arguments to function 'copy_user_highpage' make[5]: *** [mm/hugetlb.o] Error 1 I'll look at this tomorrow. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
On Mon, Nov 06, 2006 at 01:05:21AM -0700, dann frazier wrote: On Sun, Nov 05, 2006 at 01:56:28PM +0100, maximilian attems wrote: -- snipp ia64 CC mm/hugetlb.o mm/hugetlb.c: In function 'copy_huge_page': mm/hugetlb.c:54: error: too few arguments to function 'copy_user_highpage' make[5]: *** [mm/hugetlb.o] Error 1 I'll look at this tomorrow. -- dann frazier should be fixed by ths in latest trunk, please verify. we want to upload -5 soon with only the build fixes. thanks -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
Steve Langasek [EMAIL PROTECTED] writes:
On Sun, Nov 05, 2006 at 01:56:28PM +0100, maximilian attems wrote:
{standard input}:372: Error: macro requires $at register while noat in effect
make[5]: *** [arch/alpha/kernel/core_cia.o] Error 1
make[4]: *** [arch/alpha/kernel] Error 2
Taking a look at the assembler output for core_cia, this is due to use of
the ldbu, ldwu, stb, and stw instructions in asm-alpha/compiler.h, which are
instructions specific to ev56 and above. They are also guarded in the
source by an #if !defined(__alpha_bwx__). It looks like the difference is
in the assembler between gcc-4.0 and gcc-4.1; specifically, gcc-4.1 emits a
'.arch ev5' directive, where gcc-4.0 does not.
I made a patch against gcc to suppress gcc outputting .arch directives
that don't do anything useful except triggering this error, and it
went in in 4.1.1ds2-17. Unfortunately, I thought an .ev4 directive
would be the problem, while it seems to be .ev5. This updated patch
instead of alpha-no-ev4-directive.patch should help:
--- gcc/config/alpha/alpha.c.orig 2006-11-06 09:59:12.0 +0100
+++ gcc/config/alpha/alpha.c2006-11-06 09:59:06.0 +0100
@@ -9353,7 +9353,7 @@
fputs (\t.set nomacro\n, asm_out_file);
if (TARGET_SUPPORT_ARCH | TARGET_BWX | TARGET_MAX | TARGET_FIX | TARGET_CIX)
{
- const char *arch;
+ const char *arch = NULL;
if (alpha_cpu == PROCESSOR_EV6 || TARGET_FIX || TARGET_CIX)
arch = ev6;
@@ -9361,12 +9361,9 @@
arch = pca56;
else if (TARGET_BWX)
arch = ev56;
- else if (alpha_cpu == PROCESSOR_EV5)
- arch = ev5;
- else
- arch = ev4;
- fprintf (asm_out_file, \t.arch %s\n, arch);
+ if (arch)
+fprintf (asm_out_file, \t.arch %s\n, arch);
}
}
#endif
Since the errors from the assembler really indicate that these instructions
are not supported by the ev5 (gcc-4.0 has the same problem assembling the
gcc-4.1 output as gcc-4.1 itself does, due to the .arch ev5 declaration),
and this kernel code hasn't changed recently that I see, it seems to be the
case that ev5 processors are already unsupported by the current kernel in
etch. Given that no one has complained about this to date (at least that
I'm aware of), is it time to explicitly bump the baseline on alpha to ev56
for etch?
I'm not opposed to this, in fact I was planning to suggest this for
etch+1. However, this particular problem should be reasonably easy to
fix, so if anybody speaks up for ev5, we should give it a try...
--
Falk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
On Mon, Nov 06, 2006 at 09:31:08AM +0100, maximilian attems wrote: should be fixed by ths in latest trunk, please verify. verified. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
On Mon, 6 Nov 2006, Falk Hueffner wrote:
Steve Langasek [EMAIL PROTECTED] writes:
On Sun, Nov 05, 2006 at 01:56:28PM +0100, maximilian attems wrote:
{standard input}:372: Error: macro requires $at register while noat in effect
make[5]: *** [arch/alpha/kernel/core_cia.o] Error 1
make[4]: *** [arch/alpha/kernel] Error 2
Taking a look at the assembler output for core_cia, this is due to use of
the ldbu, ldwu, stb, and stw instructions in asm-alpha/compiler.h, which are
instructions specific to ev56 and above. They are also guarded in the
[...]
Since the errors from the assembler really indicate that these instructions
are not supported by the ev5 (gcc-4.0 has the same problem assembling the
gcc-4.1 output as gcc-4.1 itself does, due to the .arch ev5 declaration),
and this kernel code hasn't changed recently that I see, it seems to be the
case that ev5 processors are already unsupported by the current kernel in
etch. Given that no one has complained about this to date (at least that
I'm aware of), is it time to explicitly bump the baseline on alpha to ev56
for etch?
I'm not opposed to this, in fact I was planning to suggest this for
etch+1. However, this particular problem should be reasonably easy to
fix, so if anybody speaks up for ev5, we should give it a try...
I'm running a DNS server on an EV5. (AlphaStation 500/333) It's running
unstable, but on an old, self-compiled kernel, so I haven't had trouble
yet.
I don't know of anyone else running Debian on an EV5, and I don't really
have a strong reason for continuing to use this box over an EV56 or even a
different arch.
I'll gladly test debian kernels, and keep it more up to date, if that
would be useful.
Ivan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
On Tue, Nov 07, 2006 at 01:40:41AM +0100, Falk Hueffner wrote: Steve Langasek [EMAIL PROTECTED] writes: Given that you mention you're not running a Debian kernel at all right now, and that this code is in place upstream and nobody else seems to have complained loudly enough to get it fixed, I'm not sure how much effort we'll want to put into it if it turns out to not work on ev5, but it will still be good to know -- and if the kernel *does* work for you, that's a good reason to find a solution other than switching the kernel to build ev56 code. :) It should work, the code is guarded to be only executed on ev56+. See also the thread Ok. http://gcc.gnu.org/ml/gcc/2005-07/msg00371.html The key message seems to be http://gcc.gnu.org/ml/gcc/2005-07/msg00429.html. Obviously kernel upstream believes the current code is correct, and that this is a gcc bug. But I'm wondering why the embedded assembly in the Linux kernel can't be fixed to include .arch ev56, so that the error-checking semantics of gcc can be preserved in the general case? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
Steve Langasek [EMAIL PROTECTED] writes: Given that you mention you're not running a Debian kernel at all right now, and that this code is in place upstream and nobody else seems to have complained loudly enough to get it fixed, I'm not sure how much effort we'll want to put into it if it turns out to not work on ev5, but it will still be good to know -- and if the kernel *does* work for you, that's a good reason to find a solution other than switching the kernel to build ev56 code. :) It should work, the code is guarded to be only executed on ev56+. See also the thread http://gcc.gnu.org/ml/gcc/2005-07/msg00371.html -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
Hi Ivan,
On Mon, Nov 06, 2006 at 02:51:01PM -0500, Ivan Jager wrote:
On Mon, 6 Nov 2006, Falk Hueffner wrote:
Steve Langasek [EMAIL PROTECTED] writes:
On Sun, Nov 05, 2006 at 01:56:28PM +0100, maximilian attems wrote:
{standard input}:372: Error: macro requires $at register while noat in
effect
make[5]: *** [arch/alpha/kernel/core_cia.o] Error 1
make[4]: *** [arch/alpha/kernel] Error 2
Taking a look at the assembler output for core_cia, this is due to use of
the ldbu, ldwu, stb, and stw instructions in asm-alpha/compiler.h, which
are
instructions specific to ev56 and above. They are also guarded in the
[...]
Since the errors from the assembler really indicate that these
instructions
are not supported by the ev5 (gcc-4.0 has the same problem assembling the
gcc-4.1 output as gcc-4.1 itself does, due to the .arch ev5 declaration),
and this kernel code hasn't changed recently that I see, it seems to be
the
case that ev5 processors are already unsupported by the current kernel in
etch. Given that no one has complained about this to date (at least that
I'm aware of), is it time to explicitly bump the baseline on alpha to ev56
for etch?
I'm not opposed to this, in fact I was planning to suggest this for
etch+1. However, this particular problem should be reasonably easy to
fix, so if anybody speaks up for ev5, we should give it a try...
I'm running a DNS server on an EV5. (AlphaStation 500/333) It's running
unstable, but on an old, self-compiled kernel, so I haven't had trouble
yet.
I don't know of anyone else running Debian on an EV5, and I don't really
have a strong reason for continuing to use this box over an EV56 or even a
different arch.
I'll gladly test debian kernels, and keep it more up to date, if that
would be useful.
Yes, if you could test the etch or sid kernel (linux 2.6.17 or 2.6.18) on
your ev5 system to indicate whether these illegal instructions are a problem
in practice[1], that would be appreciated.
Given that you mention you're not running a Debian kernel at all right now,
and that this code is in place upstream and nobody else seems to have
complained loudly enough to get it fixed, I'm not sure how much effort we'll
want to put into it if it turns out to not work on ev5, but it will still be
good to know -- and if the kernel *does* work for you, that's a good reason
to find a solution other than switching the kernel to build ev56 code. :)
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
On Mon, Nov 06, 2006 at 10:02:51AM +0100, Falk Hueffner wrote:
Steve Langasek [EMAIL PROTECTED] writes:
On Sun, Nov 05, 2006 at 01:56:28PM +0100, maximilian attems wrote:
{standard input}:372: Error: macro requires $at register while noat in
effect
make[5]: *** [arch/alpha/kernel/core_cia.o] Error 1
make[4]: *** [arch/alpha/kernel] Error 2
Taking a look at the assembler output for core_cia, this is due to use of
the ldbu, ldwu, stb, and stw instructions in asm-alpha/compiler.h, which are
instructions specific to ev56 and above. They are also guarded in the
source by an #if !defined(__alpha_bwx__). It looks like the difference is
in the assembler between gcc-4.0 and gcc-4.1; specifically, gcc-4.1 emits a
'.arch ev5' directive, where gcc-4.0 does not.
I made a patch against gcc to suppress gcc outputting .arch directives
that don't do anything useful except triggering this error, and it
went in in 4.1.1ds2-17. Unfortunately, I thought an .ev4 directive
would be the problem, while it seems to be .ev5.
It gets better -- after fixing up the first bit of assembly in the source,
I've found that there's also embedded assembly in sys_titan.c which is
specific to ev6. So even emitting .arch ev56 is going to give a build
failure.
Which convinces me even more that the right answer is to fix the kernel
instead of disabling gcc's ability to sanity-check the insns used.
Patch available as soon as I get to the end of the build.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
Package: linux-2.6
Version: 2.6.18-4
Severity: serious
-- snipp alpha
CC arch/alpha/kernel/core_cia.o
{standard input}: Assembler messages:
{standard input}:250: Error: macro requires $at register while noat in effect
{standard input}:265: Error: macro requires $at register while noat in effect
{standard input}:280: Error: macro requires $at register while noat in effect
{standard input}:293: Error: macro requires $at register while noat in effect
{standard input}:329: Error: macro requires $at register while noat in effect
{standard input}:344: Error: macro requires $at register while noat in effect
{standard input}:359: Error: macro requires $at register while noat in effect
{standard input}:372: Error: macro requires $at register while noat in effect
make[5]: *** [arch/alpha/kernel/core_cia.o] Error 1
make[4]: *** [arch/alpha/kernel] Error 2
-- snipp ia64
CC mm/hugetlb.o
mm/hugetlb.c: In function 'copy_huge_page':
mm/hugetlb.c:54: error: too few arguments to function 'copy_user_highpage'
make[5]: *** [mm/hugetlb.o] Error 1
other archs fallout yet unkown,
amd64 and arm are in installed status.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397139: ftbfs alpha + ia64
On Sun, Nov 05, 2006 at 01:56:28PM +0100, maximilian attems wrote:
Package: linux-2.6
Version: 2.6.18-4
Severity: serious
-- snipp alpha
CC arch/alpha/kernel/core_cia.o
{standard input}: Assembler messages:
{standard input}:250: Error: macro requires $at register while noat in effect
{standard input}:265: Error: macro requires $at register while noat in effect
{standard input}:280: Error: macro requires $at register while noat in effect
{standard input}:293: Error: macro requires $at register while noat in effect
{standard input}:329: Error: macro requires $at register while noat in effect
{standard input}:344: Error: macro requires $at register while noat in effect
{standard input}:359: Error: macro requires $at register while noat in effect
{standard input}:372: Error: macro requires $at register while noat in effect
make[5]: *** [arch/alpha/kernel/core_cia.o] Error 1
make[4]: *** [arch/alpha/kernel] Error 2
Taking a look at the assembler output for core_cia, this is due to use of
the ldbu, ldwu, stb, and stw instructions in asm-alpha/compiler.h, which are
instructions specific to ev56 and above. They are also guarded in the
source by an #if !defined(__alpha_bwx__). It looks like the difference is
in the assembler between gcc-4.0 and gcc-4.1; specifically, gcc-4.1 emits a
'.arch ev5' directive, where gcc-4.0 does not.
Since the errors from the assembler really indicate that these instructions
are not supported by the ev5 (gcc-4.0 has the same problem assembling the
gcc-4.1 output as gcc-4.1 itself does, due to the .arch ev5 declaration),
and this kernel code hasn't changed recently that I see, it seems to be the
case that ev5 processors are already unsupported by the current kernel in
etch. Given that no one has complained about this to date (at least that
I'm aware of), is it time to explicitly bump the baseline on alpha to ev56
for etch?
Cc:ed to debian-alpha to get feedback from the user community on the
prevalence of ev5 systems today. Also cc:ed to Falk, as the last alpha
porter to touch the subarch handling in Debian's gcc packages :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
