{-
This module handles generation of position independent code and
dynamic-linking related issues for the native code generator.
This depends both the architecture and OS, so we define it here
instead of in one of the architecture specific modules.
Things outside this module which are related to this:
+ module CLabel
- PIC base label (pretty printed as local label 1)
- DynamicLinkerLabels - several kinds:
CodeStub, SymbolPtr, GotSymbolPtr, GotSymbolOffset
- labelDynamic predicate
+ module Cmm
- The GlobalReg datatype has a PicBaseReg constructor
- The CmmLit datatype has a CmmLabelDiffOff constructor
+ codeGen & RTS
- When tablesNextToCode, no absolute addresses are stored in info tables
any more. Instead, offsets from the info label are used.
- For Win32 only, SRTs might contain addresses of __imp_ symbol pointers
because Win32 doesn't support external references in data sections.
TODO: make sure this still works, it might be bitrotted
+ NCG
- The cmmToCmm pass in AsmCodeGen calls cmmMakeDynamicReference for all
labels.
- nativeCodeGen calls pprImportedSymbol and pprGotDeclaration to output
all the necessary stuff for imported symbols.
- The NCG monad keeps track of a list of imported symbols.
- MachCodeGen invokes initializePicBase to generate code to initialize
the PIC base register when needed.
- MachCodeGen calls cmmMakeDynamicReference whenever it uses a CLabel
that wasn't in the original Cmm code (e.g. floating point literals).
+ The Mangler
- The mangler converts absolure refs to relative refs in info tables
- Symbol pointers, stub code and PIC calculations that are generated
by GCC are left intact by the mangler (so far only on ppc-darwin
and ppc-linux).
-}modulePIC(cmmMakeDynamicReference,ReferenceKind(..),needImportedSymbols,pprImportedSymbol,pprGotDeclaration,initializePicBase_ppc,initializePicBase_x86)whereimportqualifiedPPC.InstrasPPCimportqualifiedPPC.RegsasPPCimportqualifiedX86.InstrasX86importPlatformimportInstructionimportSizeimportRegimportNCGMonadimportCmmimportCLabel(CLabel,pprCLabel,mkDynamicLinkerLabel,DynamicLinkerLabelInfo(..),dynamicLinkerLabelInfo,mkPicBaseLabel,labelDynamic,externallyVisibleCLabel)importCLabel(mkForeignLabel)importStaticFlags(opt_PIC,opt_Static)importBasicTypesimportPrettyimportqualifiedOutputableimportPanic(panic)importDynFlagsimportFastString---------------------------------------------------------------------------------- It gets called by the cmmToCmm pass for every CmmLabel in the Cmm-- code. It does The Right Thing(tm) to convert the CmmLabel into a-- position-independent, dynamic-linking-aware reference to the thing-- in question.-- Note that this also has to be called from MachCodeGen in order to-- access static data like floating point literals (labels that were-- created after the cmmToCmm pass).-- The function must run in a monad that can keep track of imported symbols-- A function for recording an imported symbol must be passed in:-- - addImportCmmOpt for the CmmOptM monad-- - addImportNat for the NatM monad.dataReferenceKind=DataReference|CallReference|JumpReferencederiving(Eq)cmmMakeDynamicReference::Monadm=>DynFlags->(CLabel->m())-- a monad & a function-- used for recording imported symbols->ReferenceKind-- whether this is the target of a jump->CLabel-- the label->mCmmExprcmmMakeDynamicReferencedflagsaddImportreferenceKindlbl|Just_<-dynamicLinkerLabelInfolbl=return$CmmLit$CmmLabellbl-- already processed it, pass through|otherwise=casehowToAccessLabeldflags(platformArch$targetPlatformdflags)(platformOS$targetPlatformdflags)referenceKindlblofAccessViaStub->doletstub=mkDynamicLinkerLabelCodeStublbladdImportstubreturn$CmmLit$CmmLabelstubAccessViaSymbolPtr->doletsymbolPtr=mkDynamicLinkerLabelSymbolPtrlbladdImportsymbolPtrreturn$CmmLoad(cmmMakePicReferencedflagssymbolPtr)bWordAccessDirectly->casereferenceKindof-- for data, we might have to make some calculations:DataReference->return$cmmMakePicReferencedflagslbl-- all currently supported processors support-- PC-relative branch and call instructions,-- so just jump there if it's a call or a jump_->return$CmmLit$CmmLabellbl-- ------------------------------------------------------------------------------- Create a position independent reference to a label.-- (but do not bother with dynamic linking).-- We calculate the label's address by adding some (platform-dependent)-- offset to our base register; this offset is calculated by-- the function picRelative in the platform-dependent part below.cmmMakePicReference::DynFlags->CLabel->CmmExprcmmMakePicReferencedflagslbl-- Windows doesn't need PIC,-- everything gets relocated at runtime|OSMinGW32<-platformOS$targetPlatformdflags=CmmLit$CmmLabellbl|(opt_PIC||notopt_Static)&&absoluteLabellbl=CmmMachOp(MO_AddwordWidth)[CmmReg(CmmGlobalPicBaseReg),CmmLit$picRelative(platformArch$targetPlatformdflags)(platformOS$targetPlatformdflags)lbl]|otherwise=CmmLit$CmmLabellblabsoluteLabel::CLabel->BoolabsoluteLabellbl=casedynamicLinkerLabelInfolblofJust(GotSymbolPtr,_)->FalseJust(GotSymbolOffset,_)->False_->True---------------------------------------------------------------------------------- Knowledge about how special dynamic linker labels like symbol-- pointers, code stubs and GOT offsets look like is located in the-- module CLabel.-- We have to decide which labels need to be accessed-- indirectly or via a piece of stub code.dataLabelAccessStyle=AccessViaStub|AccessViaSymbolPtr|AccessDirectlyhowToAccessLabel::DynFlags->Arch->OS->ReferenceKind->CLabel->LabelAccessStyle-- Windows-- In Windows speak, a "module" is a set of objects linked into the-- same Portable Exectuable (PE) file. (both .exe and .dll files are PEs).---- If we're compiling a multi-module program then symbols from other modules-- are accessed by a symbol pointer named __imp_SYMBOL. At runtime we have the-- following.---- (in the local module)-- __imp_SYMBOL: addr of SYMBOL---- (in the other module)-- SYMBOL: the real function / data.---- To access the function at SYMBOL from our local module, we just need to-- dereference the local __imp_SYMBOL.---- If opt_Static is set then we assume that all our code will be linked-- into the same .exe file. In this case we always access symbols directly, -- and never use __imp_SYMBOL.--howToAccessLabeldflags_OSMinGW32_lbl-- Assume all symbols will be in the same PE, so just access them directly.|opt_Static=AccessDirectly-- If the target symbol is in another PE we need to access it via the-- appropriate __imp_SYMBOL pointer.|labelDynamic(thisPackagedflags)lbl=AccessViaSymbolPtr-- Target symbol is in the same PE as the caller, so just access it directly.|otherwise=AccessDirectly-- Mach-O (Darwin, Mac OS X)---- Indirect access is required in the following cases:-- * things imported from a dynamic library-- * (not on x86_64) data from a different module, if we're generating PIC code-- It is always possible to access something indirectly,-- even when it's not necessary.--howToAccessLabeldflagsarchOSDarwinDataReferencelbl-- data access to a dynamic library goes via a symbol pointer|labelDynamic(thisPackagedflags)lbl=AccessViaSymbolPtr-- when generating PIC code, all cross-module data references must-- must go via a symbol pointer, too, because the assembler-- cannot generate code for a label difference where one-- label is undefined. Doesn't apply t x86_64.-- Unfortunately, we don't know whether it's cross-module,-- so we do it for all externally visible labels.-- This is a slight waste of time and space, but otherwise-- we'd need to pass the current Module all the way in to-- this function.|arch/=ArchX86_64,opt_PIC&&externallyVisibleCLabellbl=AccessViaSymbolPtr|otherwise=AccessDirectlyhowToAccessLabeldflagsarchOSDarwinJumpReferencelbl-- dyld code stubs don't work for tailcalls because the-- stack alignment is only right for regular calls.-- Therefore, we have to go via a symbol pointer:|arch==ArchX86||arch==ArchX86_64,labelDynamic(thisPackagedflags)lbl=AccessViaSymbolPtrhowToAccessLabeldflagsarchOSDarwin_lbl-- Code stubs are the usual method of choice for imported code;-- not needed on x86_64 because Apple's new linker, ld64, generates-- them automatically.|arch/=ArchX86_64,labelDynamic(thisPackagedflags)lbl=AccessViaStub|otherwise=AccessDirectly-- ELF (Linux)---- ELF tries to pretend to the main application code that dynamic linking does -- not exist. While this may sound convenient, it tends to mess things up in-- very bad ways, so we have to be careful when we generate code for the main-- program (-dynamic but no -fPIC).---- Indirect access is required for references to imported symbols-- from position independent code. It is also required from the main program-- when dynamic libraries containing Haskell code are used.howToAccessLabel_ArchPPC_64oskind_|osElfTargetos=ifkind==DataReference-- ELF PPC64 (powerpc64-linux), AIX, MacOS 9, BeOS/PPCthenAccessViaSymbolPtr-- actually, .label instead of labelelseAccessDirectlyhowToAccessLabel__os__-- no PIC -> the dynamic linker does everything for us;-- if we don't dynamically link to Haskell code,-- it actually manages to do so without messing thins up.|osElfTargetos,notopt_PIC&&opt_Static=AccessDirectlyhowToAccessLabeldflagsarchosDataReferencelbl|osElfTargetos=case()of-- A dynamic label needs to be accessed via a symbol pointer._|labelDynamic(thisPackagedflags)lbl->AccessViaSymbolPtr-- For PowerPC32 -fPIC, we have to access even static data-- via a symbol pointer (see below for an explanation why-- PowerPC32 Linux is especially broken).|arch==ArchPPC,opt_PIC->AccessViaSymbolPtr|otherwise->AccessDirectly-- In most cases, we have to avoid symbol stubs on ELF, for the following reasons:-- on i386, the position-independent symbol stubs in the Procedure Linkage Table-- require the address of the GOT to be loaded into register %ebx on entry.-- The linker will take any reference to the symbol stub as a hint that-- the label in question is a code label. When linking executables, this-- will cause the linker to replace even data references to the label with-- references to the symbol stub.-- This leaves calling a (foreign) function from non-PIC code-- (AccessDirectly, because we get an implicit symbol stub)-- and calling functions from PIC code on non-i386 platforms (via a symbol stub) howToAccessLabeldflagsarchosCallReferencelbl|osElfTargetos,labelDynamic(thisPackagedflags)lbl&&notopt_PIC=AccessDirectly|osElfTargetos,arch/=ArchX86,labelDynamic(thisPackagedflags)lbl&&opt_PIC=AccessViaStubhowToAccessLabeldflags_os_lbl|osElfTargetos=iflabelDynamic(thisPackagedflags)lblthenAccessViaSymbolPtrelseAccessDirectly-- all other platformshowToAccessLabel_____|notopt_PIC=AccessDirectly|otherwise=panic"howToAccessLabel: PIC not defined for this platform"-- --------------------------------------------------------------------- | Says what we we have to add to our 'PIC base register' in order to-- get the address of a label.picRelative::Arch->OS->CLabel->CmmLit-- Darwin, but not x86_64:-- The PIC base register points to the PIC base label at the beginning-- of the current CmmTop. We just have to use a label difference to-- get the offset.-- We have already made sure that all labels that are not from the current-- module are accessed indirectly ('as' can't calculate differences between-- undefined labels).picRelativearchOSDarwinlbl|arch/=ArchX86_64=CmmLabelDiffOfflblmkPicBaseLabel0-- PowerPC Linux:-- The PIC base register points to our fake GOT. Use a label difference-- to get the offset.-- We have made sure that *everything* is accessed indirectly, so this-- is only used for offsets from the GOT to symbol pointers inside the-- GOT.picRelativeArchPPCoslbl|osElfTargetos=CmmLabelDiffOfflblgotLabel0-- Most Linux versions:-- The PIC base register points to the GOT. Use foo@got for symbol-- pointers, and foo@gotoff for everything else.-- Linux and Darwin on x86_64:-- The PIC base register is %rip, we use foo@gotpcrel for symbol pointers,-- and a GotSymbolOffset label for other things.-- For reasons of tradition, the symbol offset label is written as a plain label.picRelativearchoslbl|osElfTargetos||(os==OSDarwin&&arch==ArchX86_64)=letresult|Just(SymbolPtr,lbl')<-dynamicLinkerLabelInfolbl=CmmLabel$mkDynamicLinkerLabelGotSymbolPtrlbl'|otherwise=CmmLabel$mkDynamicLinkerLabelGotSymbolOffsetlblinresultpicRelative___=panic"PositionIndependentCode.picRelative undefined for this platform"---------------------------------------------------------------------------------- utility function for pretty-printing asm-labels,-- copied from PprMach--asmSDoc::Outputable.SDoc->DocasmSDocd=Outputable.withPprStyleDoc(Outputable.mkCodeStyleOutputable.AsmStyle)dpprCLabel_asm::CLabel->DocpprCLabel_asml=asmSDoc(pprCLabell)needImportedSymbols::Arch->OS->BoolneedImportedSymbolsarchos|os==OSDarwin,arch/=ArchX86_64=True-- PowerPC Linux: -fPIC or -dynamic|osElfTargetos,arch==ArchPPC=opt_PIC||notopt_Static-- i386 (and others?): -dynamic but not -fPIC|osElfTargetos,arch/=ArchPPC_64=notopt_Static&&notopt_PIC|otherwise=False-- gotLabel-- The label used to refer to our "fake GOT" from-- position-independent code.gotLabel::CLabelgotLabel=mkForeignLabel-- HACK: it's not really foreign(fsLit".LCTOC1")NothingFalseIsData---------------------------------------------------------------------------------- We don't need to declare any offset tables.-- However, for PIC on x86, we need a small helper function.pprGotDeclaration::Arch->OS->DocpprGotDeclarationArchX86OSDarwin|opt_PIC=vcat[ptext(sLit".section __TEXT,__textcoal_nt,coalesced,no_toc"),ptext(sLit".weak_definition ___i686.get_pc_thunk.ax"),ptext(sLit".private_extern ___i686.get_pc_thunk.ax"),ptext(sLit"___i686.get_pc_thunk.ax:"),ptext(sLit"\tmovl (%esp), %eax"),ptext(sLit"\tret")]pprGotDeclaration_OSDarwin=Pretty.empty-- pprGotDeclaration-- Output whatever needs to be output once per .s file.-- The .LCTOC1 label is defined to point 32768 bytes into the table,-- to make the most of the PPC's 16-bit displacements.-- Only needed for PIC.pprGotDeclarationarchos|osElfTargetos,arch/=ArchPPC_64,notopt_PIC=Pretty.empty|osElfTargetos,arch/=ArchPPC_64=vcat[ptext(sLit".section \".got2\",\"aw\""),ptext(sLit".LCTOC1 = .+32768")]pprGotDeclaration__=panic"pprGotDeclaration: no match"---------------------------------------------------------------------------------- On Darwin, we have to generate our own stub code for lazy binding..-- For each processor architecture, there are two versions, one for PIC-- and one for non-PIC.---- Whenever you change something in this assembler output, make sure-- the splitter in driver/split/ghc-split.lprl recognizes the new outputpprImportedSymbol::Arch->OS->CLabel->DocpprImportedSymbolArchPPCOSDarwinimportedLbl|Just(CodeStub,lbl)<-dynamicLinkerLabelInfoimportedLbl=caseopt_PICofFalse->vcat[ptext(sLit".symbol_stub"),ptext(sLit"L")<>pprCLabel_asmlbl<>ptext(sLit"$stub:"),ptext(sLit"\t.indirect_symbol")<+>pprCLabel_asmlbl,ptext(sLit"\tlis r11,ha16(L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr)"),ptext(sLit"\tlwz r12,lo16(L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr)(r11)"),ptext(sLit"\tmtctr r12"),ptext(sLit"\taddi r11,r11,lo16(L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr)"),ptext(sLit"\tbctr")]True->vcat[ptext(sLit".section __TEXT,__picsymbolstub1,")<>ptext(sLit"symbol_stubs,pure_instructions,32"),ptext(sLit"\t.align 2"),ptext(sLit"L")<>pprCLabel_asmlbl<>ptext(sLit"$stub:"),ptext(sLit"\t.indirect_symbol")<+>pprCLabel_asmlbl,ptext(sLit"\tmflr r0"),ptext(sLit"\tbcl 20,31,L0$")<>pprCLabel_asmlbl,ptext(sLit"L0$")<>pprCLabel_asmlbl<>char':',ptext(sLit"\tmflr r11"),ptext(sLit"\taddis r11,r11,ha16(L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr-L0$")<>pprCLabel_asmlbl<>char')',ptext(sLit"\tmtlr r0"),ptext(sLit"\tlwzu r12,lo16(L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr-L0$")<>pprCLabel_asmlbl<>ptext(sLit")(r11)"),ptext(sLit"\tmtctr r12"),ptext(sLit"\tbctr")]$+$vcat[ptext(sLit".lazy_symbol_pointer"),ptext(sLit"L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr:"),ptext(sLit"\t.indirect_symbol")<+>pprCLabel_asmlbl,ptext(sLit"\t.long dyld_stub_binding_helper")]|Just(SymbolPtr,lbl)<-dynamicLinkerLabelInfoimportedLbl=vcat[ptext(sLit".non_lazy_symbol_pointer"),char'L'<>pprCLabel_asmlbl<>ptext(sLit"$non_lazy_ptr:"),ptext(sLit"\t.indirect_symbol")<+>pprCLabel_asmlbl,ptext(sLit"\t.long\t0")]|otherwise=emptypprImportedSymbolArchX86OSDarwinimportedLbl|Just(CodeStub,lbl)<-dynamicLinkerLabelInfoimportedLbl=caseopt_PICofFalse->vcat[ptext(sLit".symbol_stub"),ptext(sLit"L")<>pprCLabel_asmlbl<>ptext(sLit"$stub:"),ptext(sLit"\t.indirect_symbol")<+>pprCLabel_asmlbl,ptext(sLit"\tjmp *L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr"),ptext(sLit"L")<>pprCLabel_asmlbl<>ptext(sLit"$stub_binder:"),ptext(sLit"\tpushl $L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr"),ptext(sLit"\tjmp dyld_stub_binding_helper")]True->vcat[ptext(sLit".section __TEXT,__picsymbolstub2,")<>ptext(sLit"symbol_stubs,pure_instructions,25"),ptext(sLit"L")<>pprCLabel_asmlbl<>ptext(sLit"$stub:"),ptext(sLit"\t.indirect_symbol")<+>pprCLabel_asmlbl,ptext(sLit"\tcall ___i686.get_pc_thunk.ax"),ptext(sLit"1:"),ptext(sLit"\tmovl L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr-1b(%eax),%edx"),ptext(sLit"\tjmp *%edx"),ptext(sLit"L")<>pprCLabel_asmlbl<>ptext(sLit"$stub_binder:"),ptext(sLit"\tlea L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr-1b(%eax),%eax"),ptext(sLit"\tpushl %eax"),ptext(sLit"\tjmp dyld_stub_binding_helper")]$+$vcat[ptext(sLit".section __DATA, __la_sym_ptr")<>(ifopt_PICthenint2elseint3)<>ptext(sLit",lazy_symbol_pointers"),ptext(sLit"L")<>pprCLabel_asmlbl<>ptext(sLit"$lazy_ptr:"),ptext(sLit"\t.indirect_symbol")<+>pprCLabel_asmlbl,ptext(sLit"\t.long L")<>pprCLabel_asmlbl<>ptext(sLit"$stub_binder")]|Just(SymbolPtr,lbl)<-dynamicLinkerLabelInfoimportedLbl=vcat[ptext(sLit".non_lazy_symbol_pointer"),char'L'<>pprCLabel_asmlbl<>ptext(sLit"$non_lazy_ptr:"),ptext(sLit"\t.indirect_symbol")<+>pprCLabel_asmlbl,ptext(sLit"\t.long\t0")]|otherwise=emptypprImportedSymbol_OSDarwin_=empty-- ELF / Linux---- In theory, we don't need to generate any stubs or symbol pointers-- by hand for Linux.---- Reality differs from this in two areas.---- 1) If we just use a dynamically imported symbol directly in a read-only-- section of the main executable (as GCC does), ld generates R_*_COPY-- relocations, which are fundamentally incompatible with reversed info-- tables. Therefore, we need a table of imported addresses in a writable-- section.-- The "official" GOT mechanism (label@got) isn't intended to be used-- in position dependent code, so we have to create our own "fake GOT"-- when not opt_PCI && not opt_Static.---- 2) PowerPC Linux is just plain broken.-- While it's theoretically possible to use GOT offsets larger-- than 16 bit, the standard crt*.o files don't, which leads to-- linker errors as soon as the GOT size exceeds 16 bit.-- Also, the assembler doesn't support @gotoff labels.-- In order to be able to use a larger GOT, we have to circumvent the-- entire GOT mechanism and do it ourselves (this is also what GCC does).-- When needImportedSymbols is defined,-- the NCG will keep track of all DynamicLinkerLabels it uses-- and output each of them using pprImportedSymbol.pprImportedSymbolArchPPC_64os_|osElfTargetos=emptypprImportedSymbol_osimportedLbl|osElfTargetos=casedynamicLinkerLabelInfoimportedLblofJust(SymbolPtr,lbl)->letsymbolSize=casewordWidthofW32->sLit"\t.long"W64->sLit"\t.quad"_->panic"Unknown wordRep in pprImportedSymbol"invcat[ptext(sLit".section \".got2\", \"aw\""),ptext(sLit".LC_")<>pprCLabel_asmlbl<>char':',ptextsymbolSize<+>pprCLabel_asmlbl]-- PLT code stubs are generated automatically by the dynamic linker._->emptypprImportedSymbol___=panic"PIC.pprImportedSymbol: no match"---------------------------------------------------------------------------------- Generate code to calculate the address that should be put in the-- PIC base register.-- This is called by MachCodeGen for every CmmProc that accessed the-- PIC base register. It adds the appropriate instructions to the-- top of the CmmProc.-- It is assumed that the first NatCmmTop in the input list is a Proc-- and the rest are CmmDatas.-- Darwin is simple: just fetch the address of a local label.-- The FETCHPC pseudo-instruction is expanded to multiple instructions-- during pretty-printing so that we don't have to deal with the-- local label:-- PowerPC version:-- bcl 20,31,1f.-- 1: mflr picReg-- i386 version:-- call 1f-- 1: popl %picReg-- Get a pointer to our own fake GOT, which is defined on a per-module basis.-- This is exactly how GCC does it, and it's quite horrible:-- We first fetch the address of a local label (mkPicBaseLabel).-- Then we add a 16-bit offset to that to get the address of a .long that we-- define in .text space right next to the proc. This .long literal contains-- the (32-bit) offset from our local label to our global offset table-- (.LCTOC1 aka gotOffLabel).initializePicBase_ppc::Arch->OS->Reg->[NatCmmTopPPC.Instr]->NatM[NatCmmTopPPC.Instr]initializePicBase_ppcArchPPCospicReg(CmmProcinfolabparams(ListGraphblocks):statics)|osElfTargetos=dogotOffLabel<-getNewLabelNattmp<-getNewRegNat$intSizewordWidthletgotOffset=CmmDataText[CmmDataLabelgotOffLabel,CmmStaticLit(CmmLabelDiffOffgotLabelmkPicBaseLabel0)]offsetToOffset=PPC.ImmConstantDiff(PPC.ImmCLblgotOffLabel)(PPC.ImmCLblmkPicBaseLabel)BasicBlockbIDinsns=headblocksb'=BasicBlockbID(PPC.FETCHPCpicReg:PPC.LDPPC.archWordSizetmp(PPC.AddrRegImmpicRegoffsetToOffset):PPC.ADDpicRegpicReg(PPC.RIRegtmp):insns)return(CmmProcinfolabparams(ListGraph(b':tailblocks)):gotOffset:statics)initializePicBase_ppcArchPPCOSDarwinpicReg(CmmProcinfolabparams(ListGraphblocks):statics)=return(CmmProcinfolabparams(ListGraph(b':tailblocks)):statics)whereBasicBlockbIDinsns=headblocksb'=BasicBlockbID(PPC.FETCHPCpicReg:insns)initializePicBase_ppc____=panic"initializePicBase_ppc: not needed"-- We cheat a bit here by defining a pseudo-instruction named FETCHGOT-- which pretty-prints as:-- call 1f-- 1: popl %picReg-- addl __GLOBAL_OFFSET_TABLE__+.-1b, %picReg-- (See PprMach.lhs)initializePicBase_x86::Arch->OS->Reg->[NatCmmTopX86.Instr]->NatM[NatCmmTopX86.Instr]initializePicBase_x86ArchX86ospicReg(CmmProcinfolabparams(ListGraphblocks):statics)|osElfTargetos=return(CmmProcinfolabparams(ListGraph(b':tailblocks)):statics)whereBasicBlockbIDinsns=headblocksb'=BasicBlockbID(X86.FETCHGOTpicReg:insns)initializePicBase_x86ArchX86OSDarwinpicReg(CmmProcinfolabparams(ListGraphblocks):statics)=return(CmmProcinfolabparams(ListGraph(b':tailblocks)):statics)whereBasicBlockbIDinsns=headblocksb'=BasicBlockbID(X86.FETCHPCpicReg:insns)initializePicBase_x86____=panic"initializePicBase_x86: not needed"