Commit 65fec07b authored by Simon Marlow's avatar Simon Marlow

Comment to explain why we need to split proc points on x86/Darwin with -fPIC

parent 09209de4
......@@ -179,11 +179,41 @@ cpsTop hsc_env proc =
-- the entry point.
splitting_proc_points = hscTarget dflags /= HscAsm
|| not (tablesNextToCode dflags)
|| usingDarwinX86Pic
|| usingDarwinX86Pic -- Note [darwin-x86-pic]
usingDarwinX86Pic = platformArch platform == ArchX86
&& platformOS platform == OSDarwin
&& gopt Opt_PIC dflags
{- Note [darwin-x86-pic]
On x86/Darwin, PIC is implemented by inserting a sequence like
call 1f
1: popl %reg
at the proc entry point, and then referring to labels as offsets from
%reg. If we don't split proc points, then we could have many entry
points in a proc that would need this sequence, and each entry point
would then get a different value for %reg. If there are any join
points, then at the join point we don't have a consistent value for
%reg, so we don't know how to refer to labels.
Hence, on x86/Darwin, we have to split proc points, and then each proc
point will get its own PIC initialisation sequence.
This isn't an issue on x86/ELF, where the sequence is
call 1f
1: popl %reg
addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %reg
so %reg always has a consistent value: the address of
_GLOBAL_OFFSET_TABLE_, regardless of which entry point we arrived via.
-}
runUniqSM :: UniqSM a -> IO a
runUniqSM m = do
us <- mkSplitUniqSupply 'u'
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment