In trying to get the qt5webkit package running on an iMX6 device (Qt version 5.5.0 from the2015.11 Buildroot release), I am seeing run-time asserts generated by the code.
It manifests itself with the output:
ASSERTION FAILED:
isPointerTypeAlignmentOkay(reinterpret_cast<TypePtr>(ptr))
../WTF/wtf/StdLibExtras.h(102):
TypePtr reinterpret_cast_ptr(const void*)
[with TypePtr = const unsigned int*]
Segmentation fault (core dumped)
The code doing the assert check follows, and you can see it's actually checking the alignment to ensure it's okay:
template<typename Type> bool isPointerTypeAlignmentOkay(Type* ptr)
{
return !(reinterpret_cast<intptr_t>(ptr) % __alignof__(Type));
}
template<typename TypePtr> TypePtr reinterpret_cast_ptr(const void* ptr)
{
ASSERT(isPointerTypeAlignmentOkay(reinterpret_cast<TypePtr>(ptr)));
return reinterpret_cast<TypePtr>(ptr);
}
Now I understand why this is being done. From (admittedly faded) memory, early ARM chips would fault if you attempted an unaligned access and even later ones that didn't fault, still ran slower.
What I don't clearly understand is why standard code with the Buildroot distribution is failing. I'm pretty certain the issue is not in my own code since compiling and running the sample browser application (from the qt5webkit-examples Buildroot package) exhibits the same problem.
The assert is clearly within a section that's only compiled for ARM/MIPS under GCC/CLANG so it's very specific to those platforms. That means it's entirely possible that it's never been tested properly.
For now, I have added a local patch as a workaround, specifically changing the check to ensure the alignment is irrelevant:
diff --git a/Source/WTF/wtf/StdLibExtras.h b/Source/WTF/wtf/StdLibExtras.h
--- a/Source/WTF/wtf/StdLibExtras.h 2000-01-01 00:00:00.000000000 +0000
+++ b/Source/WTF/wtf/StdLibExtras.h 2000-01-01 00:00:00.000000000 +0000
@@ -86,5 +86,5 @@
template<typename Type>
bool isPointerTypeAlignmentOkay(Type* ptr)
{
- return !(reinterpret_cast<intptr_t>(ptr) % __alignof__(Type));
+ return true;
}
However, I have a few concerns about this. The first is whether or not this is actually safe on the ARM chips (specifically, for now, the Cortex-A9 variants). It appears to run okay but I'm not sure if there are subtle edge cases I should be concerned with. I'm not yet concerned about the possibility that it may run slower, especially if the alternative is that it doesn't run at all.
The second question is simply to ask if anyone else has managed to get the qt5webkit package working on ARM chips as part of Buildroot. Am I missing something blindingly obvious to the initiated? If indeed it is a fault in the standard Buildroot package, I'll probably end up submitting a patch but I don't want to do that until I understand it a little better.
In terms of the environment, we're using the Buildroot-internal toolchain on an Ubuntu 14.04 host box.
Try followings target options in buildroot menuconfig: