Re: [patches] powerpc 8xx dcbz problem

[Steven Munroe <munroesj@xxxxxxxxxx>]

Mark Mitchell wrote:
> Nathan Sidwell wrote:
>   
>> Steven Munroe wrote:
>>
>>     
>>> So just provide a patch for sysdeps/powerpc/powerpc32/8xx/ to override
>>> memset.S with a version that does not use dcbz. Then use -with-cpu=8xx
>>> for you build. This elliminates the clutter to the base but solves your
>>> chip specific problem!
>>>       
>> We're trying to avoid an 8xx-specific multilib here.
>>     
>
> Yes, we (and some of our customers) aren't eager to have lots of
> multilibs; the goal is to have binaries that can run on a variety of
> systems.  (That's why I was asking questions about dynamically selecting
> optimization strategies a while back.)
>   
yes but!

there is near infinite variation in the embedded space and managing this
will be major problem if each chip's has to have chip specific code fix
in the sprinked all over the common code. That is why Roland agreed to
add the --with-cpu support as a way to manage this. You all might be
very annoyed with me, if I had 970/power4/power5/power5+/power6/power6x
specific code cluttering up performance sensitive common code!
> Even if it's not practical to dynamically choose optimized code paths, I
> think it's important to be able to do some dynamic selection for cases
> like this.  Obviously, it's unfortunate that 8xx processors have this
> bug, but they do, and being able to distribute a single binary for a
> family of processors is an important convenience.
>
>   
So any fix/work-around should go in ports and should use --with-cpu. You
can override libc-start.c from ports/sysdeps/powerpc/powerpc32/8xx with
a version that zeros __cache_line_size for 8xx and sets its from
AT_DCACHEBSIZE otherwise.

This allows you to build a single binary, but keeps the trunc clean.