[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

            Bug ID: 100073
           Summary: Shader Disk Cache 32/64 bit detection has a flaw.
                    Missed existence of x32 ABI
           Product: Mesa
           Version: git
          Hardware: All
                OS: All
            Status: NEW
          Severity: critical
          Priority: medium
         Component: Mesa core
          Assignee: mesa-dev at lists.freedesktop.org
          Reporter: oiaohm at gmail.com
        QA Contact: mesa-dev at lists.freedesktop.org

https://cgit.freedesktop.org/mesa/mesa/commit/?id=11f0efec2e615f5233defdd8ca9693c54ea49b1f

This is the commit with the problem.


https://en.wikipedia.org/wiki/X32_ABI

This explains X32_ABI is.   I don't know if anything else like this is around
where (void *) will return 4 and there will be a different register count and
different functionality.   This will be important for software rendering
pre-building shades in cases where X32_ABI is being used to get the most
performance.    Yes Linux you can run a 32 bit and a x32 and a 64 bit at the
same time. 

As far as I know Linux is the only thing with this third mode.

I don't know what an acceptable test would be to split X32 and 32bit as they
need to be.   This is a platform particular thing.


I don't know if there are any other OS modes with different register counts and
functionality that will return the same size pointer with.

get_arch_bitness_str as function maybe totally wrong.   
https://wiki.debian.org/X32Port
In fact I am not sure if this code for bitness is right at all.

Normal convention is that 32 bit code calls 32 bit libraries.  64 bit code
calls 64 bit libraries and x32 code calls x32 libraries.
So you short out this bitness stuff with complier preprocessor flags at build
time no runtime code.   As what is recommend on the Debian site.

The current code is depending on complier solving out what may not happen in
all cases so result in a pointless waste of cpu time.

So I have this horible feeling the complete patch is wrong because it
disobeying conventions.   This is why I set this to All I don't believe this
patch is right for any platform in it current form as it depending on the
complier to transform it out by optimisation.

Yes writing it using preprocessor macros for all the platforms is a pain but
that will always solve out and would be good in a header shared.

I know a lot resort to runtime testing but with items like X32 this is not
wise.

-- 
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/20170305/4fd1312b/attachment.html>