Re: class_device_add error in SCSI with 2.6.17-rc2-g52824b6b

Re: class_device_add error in SCSI with 2.6.17-rc2-g52824b6b

[Mathieu Chouquet-Stringer]

On Wed, Apr 19, 2006 at 04:58:03PM -0500, Bob Tracy wrote:
> Similar error previously reported by me for 2.6.17-rc1, except sda got
> added fine: error occurred when attempting to add/register sdb. 
> Thankfully, you were able to append a trace...

In my case, I was able to solve the problem by replacing this call at
line 1648 in drivers/scsi/sd.c (patch attached):
strncpy(sdkp->cdev.class_id, sdp->sdev_gendev.bus_id, BUS_ID_SIZE);

by

snprintf(sdkp->cdev.class_id, BUS_ID_SIZE, "%s", sdp->sdev_gendev.bus_id);

Then it works.

While debugging the whole thing, I was printk'ing the value of
sdkp->cdev.class_id right after the strncpy call and here's what I
getting (basically only the first 4 chars + final \0): 
"0:0:"

So I guess the strncpy routine on alpha is fscked up or gcc is doing
something crazy. The function is under arch/alpha/lib/strncpy.S, time to
learn assembly.


--- linux-2.6/drivers/scsi/sd.c	2006-03-28 13:28:24.000000000 +0200
+++ linux-2.6-mat/drivers/scsi/sd.c	2006-04-20 12:12:36.000000000 +0200
@@ -1645,7 +1645,8 @@
 	class_device_initialize(&sdkp->cdev);
 	sdkp->cdev.dev = &sdp->sdev_gendev;
 	sdkp->cdev.class = &sd_disk_class;
-	strncpy(sdkp->cdev.class_id, sdp->sdev_gendev.bus_id, BUS_ID_SIZE);
+	snprintf(sdkp->cdev.class_id, BUS_ID_SIZE, "%s",
+		sdp->sdev_gendev.bus_id);
 
 	if (class_device_add(&sdkp->cdev))
 		goto out_put;


-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr
    "Le disparu, si l'on vénère sa mémoire, est plus présent et
                 plus puissant que le vivant".
           -- Antoine de Saint-Exupéry, Citadelle --

-
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: class_device_add error in SCSI with 2.6.17-rc2-g52824b6b

[Mathieu Chouquet-Stringer]

On Thu, Apr 20, 2006 at 12:14:48PM +0200, Mathieu Chouquet-Stringer wrote:
> So I guess the strncpy routine on alpha is fscked up or gcc is doing
> something crazy. The function is under arch/alpha/lib/strncpy.S, time to
> learn assembly.

Replying to myself here, i've created the following test program and
redefined strncpy to mystrncpy (I used strncpy.S and stxncpy.S from
arch/alpha/lib):

=============================================================================
#include <stdio.h>
#include <string.h>
#define FOO 50

extern char *mystrncpy(char *dest, const char *src, size_t count);

int main(int argc, char **argv)
{

	char src[FOO] = "";
	char dest[FOO];
	char letter[] = "a";
	int i;

	for (i = 0; i < FOO - 1; i++) {
		size_t beflen, aftlen;

		letter[0] = 'a' + i;
		strncat(src, letter, FOO);
		beflen = strlen(src);

		mystrncpy(dest, src, FOO);
		aftlen = strlen(dest);
		if (beflen != aftlen)
			printf("fails for strlen = %ld (copied %ld)\n",
				beflen, aftlen);
	}


	return 0;
}
=============================================================================

And here's the output using gcc version 3.4.4 (Gentoo 3.4.4-r1,
ssp-3.4.4-1.0, pie-8.7.8), note i didn't use flag except -Wall:

fails for strlen = 3 (copied 2)
fails for strlen = 4 (copied 2)
fails for strlen = 5 (copied 2)
fails for strlen = 6 (copied 2)
fails for strlen = 7 (copied 2)
fails for strlen = 11 (copied 10)
fails for strlen = 12 (copied 10)
fails for strlen = 13 (copied 10)
fails for strlen = 14 (copied 10)
fails for strlen = 15 (copied 10)
fails for strlen = 19 (copied 18)
fails for strlen = 20 (copied 18)
fails for strlen = 21 (copied 18)
fails for strlen = 22 (copied 18)
fails for strlen = 23 (copied 18)
fails for strlen = 27 (copied 26)
fails for strlen = 28 (copied 26)
fails for strlen = 29 (copied 26)
fails for strlen = 30 (copied 26)
fails for strlen = 31 (copied 26)
fails for strlen = 35 (copied 34)
fails for strlen = 36 (copied 34)
fails for strlen = 37 (copied 34)
fails for strlen = 38 (copied 34)
fails for strlen = 39 (copied 34)
fails for strlen = 43 (copied 42)
fails for strlen = 44 (copied 42)
fails for strlen = 45 (copied 42)
fails for strlen = 46 (copied 42)
fails for strlen = 47 (copied 42)


So much for this function...  I'll look at the assembly to see if I can
understand what's going on: it always copy a multiple of 8 + 2 bytes (as
in 8x + 2).
-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

[ some background here: this started as a kobject_add error from the
scsi subsystem, now it appears the strncpy routine on Alpha is broken
see http://lkml.org/lkml/fancy/2006/4/19/305 or
msgid 20060419213129.GA9148@localhost ]

On Thu, Apr 20, 2006 at 12:14:48PM +0200, Mathieu Chouquet-Stringer wrote:
> So I guess the strncpy routine on alpha is fscked up or gcc is doing
> something crazy. The function is under arch/alpha/lib/strncpy.S, time to
> learn assembly.

Replying to myself here, i've created the following test program and
redefined strncpy to mystrncpy (I used strncpy.S and stxncpy.S from
arch/alpha/lib):

=============================================================================
#include <stdio.h>
#include <string.h>
#define FOO 50

extern char *mystrncpy(char *dest, const char *src, size_t count);

int main(int argc, char **argv)
{

	char src[FOO] = "";
	char dest[FOO];
	char letter[] = "a";
	int i;

	for (i = 0; i < FOO - 1; i++) {
		size_t beflen, aftlen;

		letter[0] = 'a' + i;
		strncat(src, letter, FOO);
		beflen = strlen(src);

		mystrncpy(dest, src, FOO);
		aftlen = strlen(dest);
		if (beflen != aftlen)
			printf("fails for strlen = %ld (copied %ld)\n",
				beflen, aftlen);
	}


	return 0;
}
=============================================================================

And here's the output using gcc version 3.4.4 (Gentoo 3.4.4-r1,
ssp-3.4.4-1.0, pie-8.7.8), note i didn't use flag except -Wall:

fails for strlen = 3 (copied 2)
fails for strlen = 4 (copied 2)
fails for strlen = 5 (copied 2)
fails for strlen = 6 (copied 2)
fails for strlen = 7 (copied 2)
fails for strlen = 11 (copied 10)
fails for strlen = 12 (copied 10)
fails for strlen = 13 (copied 10)
fails for strlen = 14 (copied 10)
fails for strlen = 15 (copied 10)
fails for strlen = 19 (copied 18)
fails for strlen = 20 (copied 18)
fails for strlen = 21 (copied 18)
fails for strlen = 22 (copied 18)
fails for strlen = 23 (copied 18)
fails for strlen = 27 (copied 26)
fails for strlen = 28 (copied 26)
fails for strlen = 29 (copied 26)
fails for strlen = 30 (copied 26)
fails for strlen = 31 (copied 26)
fails for strlen = 35 (copied 34)
fails for strlen = 36 (copied 34)
fails for strlen = 37 (copied 34)
fails for strlen = 38 (copied 34)
fails for strlen = 39 (copied 34)
fails for strlen = 43 (copied 42)
fails for strlen = 44 (copied 42)
fails for strlen = 45 (copied 42)
fails for strlen = 46 (copied 42)
fails for strlen = 47 (copied 42)


So much for this function...  I'll look at the assembly to see if I can
understand what's going on: it always copy a multiple of 8 + 2 bytes (as
in 8x + 2).
-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

Re: strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

On Thu, Apr 20, 2006 at 07:11:02PM +0200, Mathieu Chouquet-Stringer wrote:
> And here's the output using gcc version 3.4.4 (Gentoo 3.4.4-r1,
> ssp-3.4.4-1.0, pie-8.7.8), note i didn't use flag except -Wall:

Same code compiled with 2.95.3 fails too (I'll be trying 4.1.0 just for
the kick of it, if it cross-compiles ok but I don't expect it to work
either).


PS: Richard, we're having troubles with at least one of your function
(strncpy) on alpha.  It appears it doesn't copy the source string
properly.
You can read a recap of the thread here:
http://groups.google.com/group/linux.kernel/browse_thread/thread/551729237671f997/11109932eae9fd93?tvc=2&q=group%3A*kernel*+strncpy+mathieu#11109932eae9fd93
-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

Re: strncpy (maybe others) broken on Alpha

[Ivan Kokshaysky]

On Thu, Apr 20, 2006 at 10:55:55PM +0200, Mathieu Chouquet-Stringer wrote:
> Same code compiled with 2.95.3 fails too (I'll be trying 4.1.0 just for
> the kick of it, if it cross-compiles ok but I don't expect it to work
> either).

Broken binutils, maybe?

Ivan.

Re: strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

On Fri, Apr 21, 2006 at 01:24:17AM +0400, Ivan Kokshaysky wrote:
> Broken binutils, maybe?

2.15.92.0.2 and 2.15 (cross compiled) fail.  What's yours?

-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

Re: strncpy (maybe others) broken on Alpha

[Bob Tracy]

Ivan Kokshaysky wrote:
> On Thu, Apr 20, 2006 at 10:55:55PM +0200, Mathieu Chouquet-Stringer wrote:
> > Same code compiled with 2.95.3 fails too (I'll be trying 4.1.0 just for
> > the kick of it, if it cross-compiles ok but I don't expect it to work
> > either).
> 
> Broken binutils, maybe?

Possible...  On my Debian system, the installed binutils package *was*
binutils_2.15-6.  I just upgraded to binutils_2.16.1cvs20060117-1 with
the related gcc and cpp packages for default 4.0 compilation, and we'll
see if that makes any difference.

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

On Fri, Apr 21, 2006 at 01:24:17AM +0400, Ivan Kokshaysky wrote:
> Broken binutils, maybe?

Stop the press, it's definitely a binutils issue. 2.16.1 doesn't trigger
the error.

-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

Re: strncpy (maybe others) broken on Alpha

[Bob Tracy]

Mathieu Chouquet-Stringer wrote:
> On Fri, Apr 21, 2006 at 01:24:17AM +0400, Ivan Kokshaysky wrote:
> > Broken binutils, maybe?
> 
> Stop the press, it's definitely a binutils issue. 2.16.1 doesn't trigger
> the error.

Still not out of the woods here :-(.  Built 2.6.17-rc2 with gcc-4.0
and binutils 2.16.91 (package name is binutils_2.16.1cvs20060117-1)
and I'm still getting the kobject_add error.

Mathieu -- you mentioned testing with a cross-compile.  Was that the
case for your reported success?  How about a native compile?  I'm
pretty sure this *is* a binutils issue, but we don't quite have it
nailed down yet.

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

On Thu, Apr 20, 2006 at 09:43:04PM -0500, Bob Tracy wrote:
> Mathieu -- you mentioned testing with a cross-compile.  Was that the
> case for your reported success?  How about a native compile?  I'm
> pretty sure this *is* a binutils issue, but we don't quite have it
> nailed down yet.

My reported success was with the cross-compiled test case.

I've recompiled 2.16.1 overnight on the alpha and i'm currently
rebuilding the kernel.  I'll keep you posted.
-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

Re: strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

On Fri, Apr 21, 2006 at 10:15:00AM +0200, Mathieu Chouquet-Stringer wrote:
> My reported success was with the cross-compiled test case.

The bad news is my test case, compiled with a native gcc version 3.4.4
and binutils version 2.16.1 doesn't work as expected.  So maybe it's
combination of gcc/binutils?  I'm booting the new kernel just to confirm
that 3.4.4 and 2.16.1 do not work.

FWIW, the cross-compiler environment was made of gcc 4.1.0 and binutils
2.16.1.

-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

Re: strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

On Fri, Apr 21, 2006 at 11:21:27AM +0200, Mathieu Chouquet-Stringer wrote:
> The bad news is my test case, compiled with a native gcc version 3.4.4
> and binutils version 2.16.1 doesn't work as expected.  So maybe it's
> combination of gcc/binutils?  I'm booting the new kernel just to confirm
> that 3.4.4 and 2.16.1 do not work.

A native gcc 3.4.4 and binutils 2.16.1 do not work...  What should we
try next?

-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

Re: strncpy (maybe others) broken on Alpha

[Bob Tracy]

Mathieu Chouquet-Stringer wrote:
> On Fri, Apr 21, 2006 at 11:21:27AM +0200, Mathieu Chouquet-Stringer wrote:
> > The bad news is my test case, compiled with a native gcc version 3.4.4
> > and binutils version 2.16.1 doesn't work as expected.  So maybe it's
> > combination of gcc/binutils?  I'm booting the new kernel just to confirm
> > that 3.4.4 and 2.16.1 do not work.
> 
> A native gcc 3.4.4 and binutils 2.16.1 do not work...  What should we
> try next?

I'll try upgrading from gcc-4.0 to gcc-4.1, and if/when that has no
effect, I'll go looking for a later binutils in Debian's "unstable"
tree (I've already had to go to the "testing" tree to get beyond gcc-3
and binutils-2.15.X).  Report to follow later today.

Item for consideration: what kind of optimization is enabled for your
test case compile vs. what's being used for the kernel build?  That's
another variable we need to sort out.  For what it's worth, I do *not*
have CONFIG_CC_OPTIMIZE_FOR_SIZE enabled: the comment about "watch out
for broken compilers" was enough to scare me off while we're trying to
chase this down.

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

On Fri, Apr 21, 2006 at 06:41:49AM -0500, Bob Tracy wrote:
> I'll try upgrading from gcc-4.0 to gcc-4.1, and if/when that has no
> effect, I'll go looking for a later binutils in Debian's "unstable"
> tree (I've already had to go to the "testing" tree to get beyond gcc-3
> and binutils-2.15.X).  Report to follow later today.

Ok.

> Item for consideration: what kind of optimization is enabled for your
> test case compile vs. what's being used for the kernel build?  That's
> another variable we need to sort out.  For what it's worth, I do *not*
> have CONFIG_CC_OPTIMIZE_FOR_SIZE enabled: the comment about "watch out
> for broken compilers" was enough to scare me off while we're trying to
> chase this down.

Well I thought of this already and tried my test case without any flags
but -Wall, with -O2 and -Os.  Same result.  I also compiled my test case
with the options used by the kernel (which ATM isn't compiled with -Os),
same thing.

I've attached to this email a tarball of what I use to test the
compiler/binutils.  It's faster than recompiling the whole kernel on
these slow machines!
-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

[-- Attachment #2: strncpy_debug.tar.gz --]
[-- Type: application/x-gzip, Size: 5065 bytes --]

Re: strncpy (maybe others) broken on Alpha

[Ivan Kokshaysky]

On Fri, Apr 21, 2006 at 01:55:56PM +0200, Mathieu Chouquet-Stringer wrote:
> I've attached to this email a tarball of what I use to test the
> compiler/binutils.  It's faster than recompiling the whole kernel on
> these slow machines!

Oops. I was using a wrong copy of strncpy.S (remained from previous
__stxncpy() debugging). What's why I wasn't able to reproduce that...

It seems that the registers $24 and $27 are mixed up in strncpy().
This fixes your test case, please check if it fixes kernel problem
as well.

Ivan.

--- strncpy_debug/strncpy.S	Thu Apr 20 14:18:05 2006
+++ strncpy.S	Fri Apr 21 17:52:04 2006
@@ -43,8 +43,8 @@
 
 	.align	4
 $multiword:
-	subq	$24, 1, $2	# clear the final bits in the prev word
-	or	$2, $24, $2
+	subq	$27, 1, $2	# clear the final bits in the prev word
+	or	$2, $27, $2
 	zapnot	$1, $2, $1
 	subq	$18, 1, $18
 
@@ -70,8 +70,8 @@
 	bne	$18, 0b
 
 1:	ldq_u	$1, 0($16)	# clear the leading bits in the final word
-	subq	$27, 1, $2
-	or	$2, $27, $2
+	subq	$24, 1, $2
+	or	$2, $24, $2
 
 	zap	$1, $2, $1
 	stq_u	$1, 0($16)

Re: strncpy (maybe others) broken on Alpha

[Bob Tracy]

Ivan Kokshaysky wrote:
> On Fri, Apr 21, 2006 at 01:55:56PM +0200, Mathieu Chouquet-Stringer wrote:
> > I've attached to this email a tarball of what I use to test the
> > compiler/binutils.  It's faster than recompiling the whole kernel on
> > these slow machines!
> 
> Oops. I was using a wrong copy of strncpy.S (remained from previous
> __stxncpy() debugging). What's why I wasn't able to reproduce that...
> 
> It seems that the registers $24 and $27 are mixed up in strncpy().
> This fixes your test case, please check if it fixes kernel problem
> as well.

With this patch applied, the test suite appears to work correctly with
ALL versions of gcc on the Alpha to which I have access.  The binutils
package is currently the 2.16.1cvs20060413-1 version from Debian's
"unstable" tree.

WITHOUT the patch, and everything else the same, gcc-4.0 and gcc-4.1
appear to work, but the gcc-3.3 build produces the bad behavior we've
been seeing.

I'm currently building a 2.6.17-rc2 kernel with gcc-4.1, the binutils
package mentioned above, and Ivan's patch.  Report to follow later.

Pending a knowledgable peer review of Ivan's patch (no insult intended:
I'm not qualified), I'd say we're close to putting this to rest.  If it
turns out the patch is the correct fix, I'm genuinely concerned about
how long this bug went undetected :-(.  The modification date of
arch/alpha/lib/strncpy.S is 28 Jul 2003 in my tree.  The stxncpy.S file
is not quite a year newer: 10 May 2004.

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: strncpy (maybe others) broken on Alpha

[Ivan Kokshaysky]

On Fri, Apr 21, 2006 at 02:37:59PM -0500, Bob Tracy wrote:
> WITHOUT the patch, and everything else the same, gcc-4.0 and gcc-4.1
> appear to work, but the gcc-3.3 build produces the bad behavior we've
> been seeing.

Actually the bug doesn't show up with gcc-4 *only* because it tends
to pack the data more tightly, so that both src[] and dest[] have different
alignment vs. gcc-3 compiled foo.c:
src 0x11ffff8f4, dest 0x11ffff926 - gcc-4
src 0x11ffff8c0, dest 0x11ffff900 - gcc-3

If you add __attribute__((aligned(8))) to both src and dest declarations
in Mathieu's foo.c, you'll see the bug is still here.

> Pending a knowledgable peer review of Ivan's patch (no insult intended:
> I'm not qualified), I'd say we're close to putting this to rest.  If it
> turns out the patch is the correct fix, I'm genuinely concerned about
> how long this bug went undetected :-(.  The modification date of
> arch/alpha/lib/strncpy.S is 28 Jul 2003 in my tree.  The stxncpy.S file
> is not quite a year newer: 10 May 2004.

Well, these things happen. I think it's not quite surprising.
First, the kernel is not overloaded with strncpy calls. ;-)
Second, strncpy was mostly used in drivers that are rarely (if at all)
used on alpha.
Third, to discover this bug you need some special combination of source
and destination alignment, source string length and byte count.

Ivan.

Re: strncpy (maybe others) broken on Alpha

[Bob Tracy]

Ivan Kokshaysky wrote:
> Well, these things happen. I think it's not quite surprising.
> First, the kernel is not overloaded with strncpy calls. ;-)

As I mentioned in an earlier private message, I hope I can be forgiven
for assuming otherwise, particularly since someone went to the trouble
of writing an architecture-specific optimized version of that function.

> Second, strncpy was mostly used in drivers that are rarely (if at all)
> used on alpha.

Which was evidently the case, since this problem didn't surface until
the strncpy() call was added to sd.c.

> Third, to discover this bug you need some special combination of source
> and destination alignment, source string length and byte count.

I'm happy to report my Alpha is now up and running on 2.6.17-rc2, so
the fix works for me.  Thanks to discussion participants for their time
and trouble!

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

On Fri, Apr 21, 2006 at 05:49:17PM -0500, Bob Tracy wrote:
> > Second, strncpy was mostly used in drivers that are rarely (if at all)
> > used on alpha.
> 
> Which was evidently the case, since this problem didn't surface until
> the strncpy() call was added to sd.c.

Yeah most of the drivers I was looking at use snprintf and friends.

> I'm happy to report my Alpha is now up and running on 2.6.17-rc2, so
> the fix works for me.  Thanks to discussion participants for their time
> and trouble!

Thanks to you too:
-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

Re: strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

On Fri, Apr 21, 2006 at 06:22:23PM +0400, Ivan Kokshaysky wrote:
> Oops. I was using a wrong copy of strncpy.S (remained from previous
> __stxncpy() debugging). What's why I wasn't able to reproduce that...
> 
> It seems that the registers $24 and $27 are mixed up in strncpy().
> This fixes your test case, please check if it fixes kernel problem
> as well.

Well done, it indeed fixed the test case.  I'll try the kernel when I
get back home...

While we're at it, next week, I'll exercise the other functions to make
sure they also work as they should.

Thanks Ivan and Bob for your time, valuable feedback and work!!!
-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

Re: strncpy (maybe others) broken on Alpha

[Bryan Østergaard]

On Fri, Apr 21, 2006 at 11:50:28AM +0200, Mathieu Chouquet-Stringer wrote:
> On Fri, Apr 21, 2006 at 11:21:27AM +0200, Mathieu Chouquet-Stringer wrote:
> > The bad news is my test case, compiled with a native gcc version 3.4.4
> > and binutils version 2.16.1 doesn't work as expected.  So maybe it's
> > combination of gcc/binutils?  I'm booting the new kernel just to confirm
> > that 3.4.4 and 2.16.1 do not work.
> 
> A native gcc 3.4.4 and binutils 2.16.1 do not work...  What should we
> try next?
> 
For what it's worth, I've found gcc 3.4.4 to be bad on gentoo. If I
compile any binutils-2.16.[01] versions with 3.4.4 ld segfaults when
trying to compile gmp. I don't know of any binutils related problems
when using gcc 3.4.6 currently.

Regards,
Bryan Østergaard
-
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: strncpy (maybe others) broken on Alpha

[Ivan Kokshaysky]

On Thu, Apr 20, 2006 at 07:11:02PM +0200, Mathieu Chouquet-Stringer wrote:
> Replying to myself here, i've created the following test program and
> redefined strncpy to mystrncpy (I used strncpy.S and stxncpy.S from
> arch/alpha/lib):

...

> And here's the output using gcc version 3.4.4 (Gentoo 3.4.4-r1,
> ssp-3.4.4-1.0, pie-8.7.8), note i didn't use flag except -Wall:
> 
> fails for strlen = 3 (copied 2)
> fails for strlen = 4 (copied 2)

I'm unable to reproduce this with the toolchains that I have.

Ivan.

Re: strncpy (maybe others) broken on Alpha

[Mathieu Chouquet-Stringer]

On Fri, Apr 21, 2006 at 01:22:27AM +0400, Ivan Kokshaysky wrote:
> I'm unable to reproduce this with the toolchains that I have.

Ha, that's good news: which versions?

-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr