Bug 193043 - [CMake][WTF] Finesse i386 architecture detection
Summary: [CMake][WTF] Finesse i386 architecture detection
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: CMake (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-27 03:33 PST by Jim Mason
Modified: 2018-12-28 05:02 PST (History)
1 user (show)

See Also:


Attachments
Patch (1.31 KB, patch)
2018-12-27 04:18 PST, Jim Mason
no flags Details | Formatted Diff | Diff
Patch (1.31 KB, patch)
2018-12-27 04:23 PST, Jim Mason
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Mason 2018-12-27 03:33:24 PST
WTF processor architecture is being determined via CMAKE_SYSTEM_PROCESSOR.  On systems which support uname, this is initialized to `uname -p`.

However, the tricky bit is that on some OSes, `uname -p` returns 'i386' for both 32-bit and 64-bit members of the Intel processor family.  Thus, in this case, we must check the pointer size to determine the actual architecture.
Comment 1 Jim Mason 2018-12-27 04:18:49 PST
Created attachment 358107 [details]
Patch
Comment 2 EWS Watchlist 2018-12-27 04:21:18 PST
Attachment 358107 [details] did not pass style-queue:


ERROR: CMakeLists.txt:105:  No trailing spaces  [whitespace/trailing] [5]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 3 Jim Mason 2018-12-27 04:23:11 PST
Created attachment 358108 [details]
Patch

Fixed style fault
Comment 4 Alexey Proskuryakov 2018-12-27 11:27:48 PST
Comment on attachment 358108 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=358108&action=review

> CMakeLists.txt:98
> +    # On some OSes, `uname -p` always reports i386 for all members

How will we know in the future that this hack can be removed? Can you leave any pointers at all?
Comment 5 Jim Mason 2018-12-27 13:34:29 PST
(In reply to Alexey Proskuryakov from comment #4)
> How will we know in the future that this hack can be removed? Can you leave
> any pointers at all?

There is no intention that this should ever be removed; it is necessary because of the semantics of uname -p:

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

As can be observed from the link above, many operating systems return 'i386' for `uname -p` although they are in fact 64-bit.  For correct operation, it must be checked in this case whether the target is actually 32- or 64-bits.  See for example:

    https://cmake.org/pipermail/cmake/2007-March/013134.html
Comment 6 Jim Mason 2018-12-28 05:02:18 PST
I am going to withdraw this patch for now.

CMAKE_SYSTEM_PROCESSOR is not ideal, as i386 is ambiguous; however, I am not sure there is a best-practices alternative for architecture determination in CMake.

As for the patch, my doubt is whether CMAKE_SIZEOF_VOID_P will yield the expected result if the target architecture is different to the build architecture.

For now, users who are affected by the i386 ambiguity can override the value of CMAKE_SYSTEM_PROCESSOR to work within the existing semantics.  That is not ideal, but now I can think of no better way that does not introduce some other problem.