[OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14

Andrew Deason adeason@sinenomine.net
Tue, 31 May 2011 13:13:34 -0500


On Tue, 31 May 2011 12:14:31 -0500
Andrew Deason <adeason@sinenomine.net> wrote:

> Or I can just find it by commenting stuff out and seeing when the
> _memset ref goes away. It appears to be this loop that's causing it, in
> afs_RebuildDynroot lines 378/379:
> 
>     for (i = 0; i < NHASHENT; i++)
>             dirHeader->hashTable[i] = 0;
> 
> which makes sense; that's pretty easily optimizable into a memset.
> 
> I'll get a simpler demonstration together to submit to Oracle.

Also, Jeff, if you want a quick workaround, you can change -O to -O2 or
just leave out the -O option. I think changing the value of KERN_OPTMZ
in src/cf/osconf.m4 should be enough...

And now I'm not completely sure if this is a bug or if we're just
missing the magic incantation to make this not happen. A simple test
case:

void
foo(short *arr)
{
    int i;
    for (i = 0; i < 256; i++)
        arr[i] = 0;
}

If you compile with 'cc foo.c -c -o foo.o -O3', you get a reference to
_memset. If you compile with -O2 or below, you don't. Passing
-xbuiltin=%none, any of the -xno*lib or -xc99 etc options don't seem to
change anything. With older versions of Sun/Solaris Studio, it never
seems to call _memset.

The Oracle documentation on this is puzzling to me:
<http://download.oracle.com/docs/cd/E19205-01/821-1384/gjzku/index.html>

It says "The following table lists runtime support functions that may be
called in code compiled to run in the Solaris kernel, as a result of
source code translation by the C compiler." the table includes _memset,
_memcpy, et al. Then it says

"Note that some versions of the kernel do not provide _memmove(),
_memcpy(), or _memset(), but do provide kernel mode analogues of the
user mode routines memmove(), memcpy(), and memset()."

But it doesn't say how to avoid it. I'm not sure if there's a compiler
flag we're missing here, or if it's not supported to use -O3 for kernel
modules, or... ? Or it's just a bug. It's also interesting that this
doesn't happen on amd64, though I assume that's just because it uses
different arch-specific optimizations.

I don't know, should I just try to file a bug anyway, or should we try
to get someone with a support contract to say something?

-- 
Andrew Deason
adeason@sinenomine.net