www-client/ungoogled-chromium: debug build fails on ppc64 #365
Comments
I'm
Agreed! Do you have a solution that could go straight to ungoogled-chromium repository?
It would be best if you could prepare and submit the PR, you have the hardware after all! |
Offered in ungoogled-software/ungoogled-chromium#3008. The V8 issue is here. Ironically, submitting it required setting up a Google account – exactly the kind of thing one wishes to avoid by using ungoogled software.
OK, will do. |
Emerging a regular release build of www-client/ungoogled-chromium-126.0.6478.182_p1 with these flags works fine on ppc64:
Adding
debugand-official(but not-officialalone) causes the build to fail at the points described below.Highway
This is the same issue as encountered by Firefox in their bundled Highway on ppc64, with the same solution: define the preprocessor symbol
TOOLCHAIN_MISS_ASM_HWCAP_H.... and so on for
vec_mulo,vec_cmplt,vec_cmpeqandvec_cmpne. This is Highway trying to call variants of VSX vector intrinsics only available on POWER10, whereas my system is POWER9. The Highway detection headers do deduce POWER9 to be the most eligible target here, but they also default to building for dynamic switching between the best "attainable" targets, which for PPC are defined to always include POWER10. The solution is to build only the single most suitable target for static use by defining the preprocessor symbolHWY_COMPILE_ONLY_STATIC.These two symbols can be defined specifically for Highway by adding something like this to
src_prepare()(e.g. right before the "Removing bundled libraries" step):These Highway problems occur only in the debug build due to third_party/highway apparently being pulled in by third_party/distributed_point_functions, which is enabled by the
use_debugGN flag. However, as defining the above symbols verifiably doesn't hurt release builds, they may as well always be defined on ppc64 in case the situation changes and Highway ends up in regular builds as well.Ungoogled Chromium patches
This is a continuation of what was discussed in ungoogled-software/ungoogled-chromium#2034: the ebuild enables DCHECK when
debugis inUSE, but the UGC patches don't touch portions that are only compiled when DCHECK is enabled, leading to this inconsistency. This simple patch – like gringus's in the above issue – solves the problem when applied after the UGC patches:As this appears to be architecture-independent, the patching should probably be done unconditionally.
This keeps coming up and is trivial to solve. Perhaps the fix should be proposed to UGC proper once more?
V8
(The output is from a build with the flag
v8_optimized_debug=falseadded to the GN config, as without that the stack trace only shows the numeric offsets.)This is caused by my kernel having a 4k page size instead of the 64k more common on PPC platforms. V8's MemoryAllocator allocates chunks based on a platform-specific hardcoded size, which the lower-level MutablePageMetadata and ActiveSystemPages expect to be at most 64 operating system page sizes. The OS page size is queried at runtime with
sysconf(_SC_PAGESIZE)and correctly set to 4k on my system, but due to the hardcoded size assuming 64k pages on PPC64, the allocated chunks end up too big and the invariant doesn't hold. The hardcoded size can be fixed by adding something like this tosrc_prepare()(e.g. after the Highway fix):This is kind of a dirty hack. A more proper fix would be to test for a 4k-selecting preprocessor symbol in the
#ifcondition (which is already kind of done, just with an AIX-specific one that also enables AIXisms elsewhere) and expose this as a GN flag. I'll take a look at the situation in the main V8 repository and see about raising an issue on this there.The invariant appears to be violated in regular builds as well but only causes the build to fail when the DCHECK enforcing it is enabled. This suggests the fix should not be confined to debug builds – and also illustrates how useful it is to have support for proper debug builds in this ebuild, so thank you for that!
Conclusion
The above fixes allow the merge to complete without issues and should have no undue effect on non-ppc64 (or non-4k) systems. The resulting binary works alright – though naturally rather more slowly than a release build – but keeps emitting errors to the console about failing memory-related sanity checks, which I'm hoping are linked to the issue I need the debug build for to begin with. I'll be looking into these next.
I won't have access to a computer for the next couple of weeks, but I can prepare a pull request after that if this seems too involved to address through snippets.
The text was updated successfully, but these errors were encountered: