[Mesa-dev] [Bug 100073] Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=100073

oiaohm at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |critical

--- Comment #5 from oiaohm at gmail.com ---
https://wiki.debian.org/Multiarch

Sorry to say this is not minor the Darren Salt triple patch reminded me exactly
why you cannot split by 32 and 64 bit and store in the users created
directories.

The reality is under Debian you can be used qemu usermode to have a program
every Architecture supported by Debian running at the exactly the same time
using the exactly the same user accessible directories.

Timothy Arceri
> It's not really breakage, its just that the 32-bit cache would get deleted should you be switching between different Mesa builds.

Yes this is breakage because this can be happening every context switch between
processes on a Multiarch installed Debian due to changing architecture and
different architectures been different levels of library versions.   So fairly
much resulting in the cache being worthless.

Yes x32 ABI under Linux will be running a different version Mesa to what i386
ABI will be running.   Because both have void * pointers 4 bytes in size
calling them 32 bit is wrong.  x32 is closer to 64 bit and uses a different
library.

The triplet patch will work in all these cases.   Also it does not result in
junk code.

> Yeah and it's tested once at screen creation so it's not even worth worrying about.

This would be fine other than the fact more often than not these things are are
done only once and are not done properly become points in the code base of
incompatibilities on platform change.  Also extra areas where the complier
could attempt to-do a smart modification and get it wrong.   Compliers
optimisers will hunt out dead code and attempt to remove it someone
incorrectly.  Best option is never put in any code that will not be on a
possible code run path in the final binary.  If you do include dead code path
code expect at some point a complier to-do something stupid to you.   Yes its
better to comment or macro out code than leave it to the complier to think.

Each of these cases of dead code removal errors can be like a random shot gun
effect across the final binary.


Jan Vesely
>wouldn't it be easier if the subdirectories were based on timestamp itself?

https://reproducible-builds.org/docs/timestamps/

Sorry the idea of using timestamps is really totally invalid.   It is possible
to have two or more different builds with exactly the same timestamp coming
more common as systems are getting more set-up for reproducible builds are are
basically faking time to the build to get consistency of produced binary.

So you would need to generate something off of the complier flags, complier and
source version.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170307/8c9250ab/attachment.html>