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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Mar 11 03:36:19 UTC 2017


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

--- Comment #25 from oiaohm at gmail.com ---
(In reply to Emil Velikov from comment #24)
> On 10 March 2017 at 18:51, Steven Newbury <steve at snewbury.org.uk> wrote:
> > On Fri, 2017-03-10 at 13:27 +0000, bugzilla-daemon at freedesktop.org
> > wrote:
> >> Comment # 23 on bug 100073 from Grazvydas Ignotas
> >> (In reply to oiaohm from comment #21)
> >> > This is why I am so upset.   As soon as this comes though I have
> >> possible
> >> > trouble with miss matched mesa versions crossing with each other in
> >> a cache
> >> > directory and being hard to debug.
> >> That will only happen if you force the same modify timestamp on
> >> several
> >> variations of mesa that are built for matching pointer size. Do you
> >> really
> >> think it's likely to happen in practice?
> >
> > I believe that's exactly what happens with reproducible builds:
> > https://reproducible-builds.org/
> >
> Take another look - there's nothing which mentions or suggests that
> the binaries must have the same timestamps.
> The rule of the game is to produce identical binaries, which is true
> even when we had the timestamp file.
> 
> And if you're in doubt, do try it on your end - the instructions and
> package(s) will help you double-check ;-)
> 
> -Emil

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

I gave this link before you need to read it.

SOURCE_DATE_EPOCH is what you are told to use for time stamp values inside
source code.  That is not complier or arch unique.

You will be facing libfaketime or equal methods that freeze the clock at
SOURCE_DATE_EPOCH to catch cases of developers who have done the wrong thing.

If you look into the existing package on debian that are built multi arch as
reproducible builds you will already see many cases where they are the same
source the binary files have the exact identical timestamps on them.

https://packages.debian.org/stretch/mesa-utils
>From here download the amd64 and the arm64 check timestamps on the files and
they are absolutely identical.

In fact you can pick any arch in the list there and they are all 23 December
2016 at 1:58 I could go right to the second identical.

So there is no way to split architecture on timestamp it does not work in the
existing real world.

I know don't want to depend on build system.

I have a nightmare multi arch support means you need something like the GNU
triplet.   With complier variation like llvm having __ILP32__ for i386 and gcc
not and win32 and win64 defined in visual studio at the same time and so on.  
Cannot use C macros to solve this effectively.   

Runtime Detection also end up in a huge mountain of code that ends up buggy as
all get out due to the C macro issues need to pick between different arch
detections.   Next part is complete hell where llvm can throw error because it
finding never used code.  There is no promise that gcc will not add dead code
detection.   Basically the first lot of code is complier dependant that I
complained about as being wrong.

To make runtime detection be running the right detections you are back to the
build system providing something like a GNU triplet.

What is usable is hash the binary that will cost a lot of cpu time or used the
GNU triplet from the build system and SOURCE_DATE_EPOCH as 1 value.

Last modification time of the source is the SOURCE_DATE_EPOCH or should be.  
So any patches to source should change that value as long as the party doing it
right. 

Please note due to mesa being MIT license it lack a clause that GPL where
modified source must update timestamp.  That limits the effectiveness of using
SOURCE_DATE_EPOCH.

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


More information about the mesa-dev mailing list