Re: 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]
gclcvs (was Re: Alpha)
Greetings! The package builds fine, it appears. 1) could you please install fakeroot 2) I can make and upload by-hand builds if someone tells me they will be installed. acl2/hppa and maxima/ppc uploads have thus far been ignored. 3) Is my success a sign that this machine is trailing sid in some critical installed packages? -- Camm Maguire[EMAIL PROTECTED] == The earth is but one country, and mankind its citizens. -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gclcvs
Camm Maguire [EMAIL PROTECTED] writes: Greetings! The package builds fine, it appears. 1) could you please install fakeroot done 2) I can make and upload by-hand builds if someone tells me they will be installed. acl2/hppa and maxima/ppc uploads have thus far been ignored. I don't think that's a good idea, it could lead to trouble with security updates. 3) Is my success a sign that this machine is trailing sid in some critical installed packages? It was up-to-date as of about 3 days ago... I've now updated it to the latest ftp.de.debian.org state. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
TAKEN: combo pci card: dual uw scsi + ethernet
This card has been spoken for. On Sat, Nov 04, 2006 at 09:09:38PM -0800, Gregory P. Smith wrote: I have one of these available to anyone who wants it and is willing to pay shipping: DEC/Compaq/HP part number 30-49225-01 This is a DEC branded PCI card, its got dual ultra wide scsi controllers and a 10/100 ethernet interface on it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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]
Re: gclcvs (was Re: Alpha)
On Mon, Nov 06, 2006 at 02:00:08PM -0500, Camm Maguire wrote: Greetings! The package builds fine, it appears. Um, I seem to be missing part of this conversation. Are we still talking about the gclcvs package that was giving me syscall problems when I tried to build it, or an updated version of some kind? 1) could you please install fakeroot 2) I can make and upload by-hand builds if someone tells me they will be installed. acl2/hppa and maxima/ppc uploads have thus far been ignored. If we're still talking about gclcvs on alpha, I would at least like to see what the autobuilder does with this same package; maybe the problem is specific to my system, in which case it's ok, or maybe the problem affects the autobuilder as well in which case we have a supportability problem. -- 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]
Re: 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]
Re: 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]
Re: 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]
Re: Bug#397139: ftbfs alpha + ia64
* Falk Hueffner wrote: This updated patch instead of alpha-no-ev4-directive.patch should help: Are you going to add this patch to the next gcc-4.1 upload? Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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]
