[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

--- Comment #22 from oiaohm at gmail.com ---
(In reply to Timothy Arceri from comment #19)
> (In reply to oiaohm from comment #17)
> > (In reply to Timothy Arceri from comment #15)
> > > (In reply to oiaohm from comment #12)
> > > > (In reply to Timothy Arceri from comment #11)
> > > > > (In reply to oiaohm from comment #9)
> > > > > > Jan Vesely
> > > > > > <b>If the pointer size is the same and the timestamp is the same, the cache
> > > > > > will be reused, not deleted, and the problem does not exist.</b>
> > > > > > 
> > > > > > I have a little problem. I have x32 and i386.   So pointer size is the same
> > > > > > timestamp and contents of cache should be different.   This will happen if I
> > > > > > am running a reproducible build with frozen time.   This can also happen if
> > > > > > you make to 64 library builds with frozen time because the two builds will
> > > > > > have the same timestamps even if they are completely different versions of
> > > > > > mesa incompatible disc cache requirements.
> > > > > > 
> > > > > > https://reproducible-builds.org/docs/timestamps/
> > > > > > 
> > > > > > The reason I provided this link is time is no longer trust-able as a unique
> > > > > > value.  Do note the usage of libfaketime its really simple to forget you
> > > > > > still have that loaded after doing a reproducible build so the clock is not
> > > > > > in fact ticking forwards for anything you are doing you wake up when you
> > > > > > finally do something that is dependant on the clock in fact ticking.   So
> > > > > > you need to look at other sources to get unique value.
> > > > > 
> > > > > x32 should end up in the ilp-32 directory. That's what the __ILP32__ is
> > > > > meant to do. Even if it didn't and the cache wasn't deleted because all your
> > > > > arch builds had the same timestamp it still wouldn't matter because the
> > > > > timestamp is used to identify the Mesa version not the arch, the arch
> > > > > doesn't matter in terms of the cache it will work just fine. The only reason
> > > > > for the different dirs is because we have no way of knowing if the different
> > > > > timestamps are the same Mesa version
> > > > 
> > > > 1 if you are using timestamp it ID mesa version just use mesa version.
> > > 
> > > We can't, distros patch Mesa we can't depend on the version numbers being an
> > > accurate representation of the source that was use to compile a Mesa
> > > binaray. There is an option to do a sha of the binaries but that is a little
> > > more complex for opengl than it is for vulkan (where it is currently used by
> > > Intel).
> > 
> > Distribution will block using timestamp.  So timestamp cannot be used to
> > perform task.
> 
> I'm pretty sure that's what Vulkan drivers were already doing in the
> previous release. If distros are going to disable features I can't stop that.
> 
> > 
> > Hashing to support your usage case might be the only way.
> 
> Happy for patches to implement this.
> 
> > > 
> > > > 
> > > > Next do read what x32 API is 
> > > > 
> > > > https://en.wikipedia.org/wiki/X32_ABI
> > > > There is a different count in registers between i386 and x32.  So yes they
> > > > both report as ilp-32
> > > 
> > > gcc only sets the __ILP32__ flag for x32 not i386. Clang may differ I'm not
> > > sure, but it's not a major concern for me right now.
> > > 
> > http://stackoverflow.com/questions/34011718/is-ilp32-and-i386-a-valid-
> > configuration
> > Yes Clang sets __ILP32__ on i386 build modes.
> > 
> > __ILP32__ is a valid description for i386.   Should be presumed as being
> > possible to be set in i386.
> > 
> > In fact gcc not having __ILP32__ set for i386 could be called a bug. 
> > Depending on __ILP32__ to split i386 and x32 mode is depending on complier
> > behaviour not specification defined behaviour.
> 
> We want to avoid hooks into the build system. If you have a better idea how
> to do this than is currently done please submit a patch for review.

https://patchwork.freedesktop.org/patch/141891/
This patch almost does it.

The person here goes around a different.   Since you are using
autotools/configure script it has --target= that it either works out or your
provide.   This is the triplet.   This ready exist in configure as target_alias
and Macro: AC_CANONICAL_TARGET will get you target no matter what.

DEFINES="${DEFINES} -DCACHE_ARCH=\\\"$target\\""

But I will have to go through the complete configure because I would think it
strange if you have not already passed the target in somewhere for something to
the source code.

Might need something for platforms as fall back for those that are not Linux. 
And not using autotools.

When you say build system hooks does that include adding extra to configure or
using something it provides.  Since if complier stupid as long a configure does
the right thing it does not matter.

The target triplet should be-correct and complier neutral.

> 
> There is no shader cache for software renderers so this, or any other issues
> to do with caching for software renders in not a current concern. It would
> be more likely that we would use the gpu_id as a way to distinguish between
> implementations anyway.

-- 
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/20170310/736f5eca/attachment.html>