[Webkit-unassigned] [Bug 198274] REGRESSION(r244766): [GTK] 2.25.1 does not build on 32-bit ARM due to bit-packing assertion, requires -DENABLE_DARK_MODE_CSS=OFF
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Jun 7 09:59:10 PDT 2019
https://bugs.webkit.org/show_bug.cgi?id=198274
Michael Catanzaro <mcatanzaro at igalia.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pvollan at apple.com,
| |simon.fraser at apple.com,
| |timothy at apple.com
Summary|[GTK] 2.25.1 does not build |REGRESSION(r244766): [GTK]
|on 32-bit ARM due to |2.25.1 does not build on
|bit-packing assertion, |32-bit ARM due to
|requires |bit-packing assertion,
|-DENABLE_DARK_MODE_CSS=OFF |requires
| |-DENABLE_DARK_MODE_CSS=OFF
--- Comment #6 from Michael Catanzaro <mcatanzaro at igalia.com> ---
CCing some people who have edited these structs recently.
I stole from https://stackoverflow.com/a/43434880/1120203:
#define COMPILE_TIME_SIZEOF(t) template<int s> struct SIZEOF_ ## t ## _IS; \
struct foo { \
int a,b; \
}; \
SIZEOF_ ## t ## _IS<sizeof(t)> SIZEOF_ ## t ## _IS;
COMPILE_TIME_SIZEOF(StyleRareInheritedData);
COMPILE_TIME_SIZEOF(GreaterThanOrSameSizeAsStyleRareInheritedData);
With this, I learned:
* The size of both structs on x86_64 is currently 272
* The size of StyleRareInheritedData on ARM is currently 224
* The size of GreaterThanOrSameSizeAsStyleRareInheritedData on ARM is currently 216. Bad!
Before r244766 "[GTK] Support prefers-color-scheme media query", the size of both structs on ARM was 216, so the dark mode CSS is to "blame," even though that change itself looks good; the problem had just been latent before.
The very first thing I tried was moving void* customPropertyDataRefs[1] in GreaterThanOrSameSizeAsStyleRareInheritedData from the bottom of the struct to up between TextDecorationThickness thickness and unsigned bitfields[4], which successfully increased the size of GreaterThanOrSameSizeAsStyleRareInheritedData to 224. Of course, this sort of defeats the goal of ensuring that StyleRareInheritedData remains small, but the logic behind the desired packing is quite unclear. Obviously it must be possible to reduce the size of StyleRareInheritedData down to 216 bytes by moving everything around, but this would reduce the readability of the struct, and since this isn't code I'm familiar with, I'd rather not touch that myself, so my patch will just increase the size of GreaterThanOrSameSizeAsStyleRareInheritedData to keep things simple.
After this change, both structs are 224 bytes on ARM. StyleRareInheritedData remains unchanged at 272 bytes on x86_64. But GreaterThanOrSameSizeAsStyleRareInheritedData increases to 280 bytes on x86_64. Not ideal, but again, I really don't understand how to keep the size down without reordering everything to be exactly the same order as GreaterThanOrSameSizeAsStyleRareInheritedData, and even then the order of the members of GreaterThanOrSameSizeAsStyleRareInheritedData seems pretty arbitrary. So other reviewers' opinions would be great here.
I *suspect* this change will allow us to remove this obsolete member from GreaterThanOrSameSizeAsStyleRareInheritedData:
#if PLATFORM(IOS_FAMILY)
Color compositionColor; // FIXME: this has gone.
#endif
which is probably currently needed to prevent iOS from encountering this build failure. But of course, no way to know without first trying it on EWS.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190607/8c41b5ab/attachment-0001.html>
More information about the webkit-unassigned
mailing list