[Webkit-unassigned] [Bug 164588] Build broken for 32-bit x86 after r208306 with GCC 4.9

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=164588

--- Comment #3 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to comment #2)
> Does it work, though??? Is it really possible to have a shared library with
> position-dependent code? I do not think removing -fPIC could be right...?

What I tried was just removing the fPIC flag from JavaScriptCore/heap/Heap.cpp which is (right now) the only user of x86_cpuid() via crossModifyingCodeFence().

Doing this with cmake seems difficult (not even sure if its possible), because the fPIC argument gets passed automatically for any library via ${CMAKE_SHARED_LIBRARY_CXX_FLAGS} (for the whole library and not for a single file).

So I managed to get it build by manually editing the ninja recipes generated to remove the fPIC variable from JavaScriptCore/heap/Heap.cpp

It seems to work, but its hard to tell if something is broke as I don't even know what is the purpose of this crossModifyingCodeFence() thing or when its used.

And removing -fPIC for the whole JavaScriptCore library seems not something we want to do in any case.

I see crossModifyingCodeFence is defined as std::atomic_thread_fence(std::memory_order_seq_cst) for non x86 cpus. Maybe that could work also for an x86 cpu?.


Another option is to modify that assembly to make it happy with gcc-4.9 on x86-32 bits. Here seems to be some interesting notes about this: http://sam.zoy.org/blog/2007-04-13-shlib-with-non-pic-code-have-inline-assembly-and-pic-mix-well


But is hard to try to modify that without knowing what is x86_cpuid() actually doing, how to test it, or what is the purpose of crossModifyingCodeFence().


Filip could you advice us what to do here to fix this?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161110/d6a72340/attachment-0001.html>