[Git][ghc/ghc][wip/backport/9.0/T18857] CmmToLlvm: Declare signature for memcmp

[Moritz Angermann]

Moritz Angermann pushed to branch wip/backport/9.0/T18857 at Glasgow Haskell Compiler / GHC


Commits:
a3e195ae by Moritz Angermann at 2020-11-25T10:38:45+08:00
CmmToLlvm: Declare signature for memcmp

Otherwise `opt` fails with:

    error: use of undefined value '@memcmp$def'

- - - - -


4 changed files:

- compiler/GHC/CmmToLlvm/Base.hs
- rts/linker/Elf.c
- rts/linker/elf_reloc_aarch64.c
- testsuite/driver/testlib.py


Changes:

=====================================
compiler/GHC/CmmToLlvm/Base.hs
=====================================
@@ -475,14 +475,17 @@ getUniqMeta s = getEnv (flip lookupUFM s . envUniqMeta)
 ghcInternalFunctions :: LlvmM ()
 ghcInternalFunctions = do
     platform <- getPlatform
+    dflags <- getDynFlags
     let w = llvmWord platform
+        cint = LMInt $ widthInBits $ cIntWidth dflags
+    mk "memcmp" cint [i8Ptr, i8Ptr, w]
     mk "memcpy" i8Ptr [i8Ptr, i8Ptr, w]
     mk "memmove" i8Ptr [i8Ptr, i8Ptr, w]
     mk "memset" i8Ptr [i8Ptr, w, w]
     mk "newSpark" w [i8Ptr, i8Ptr]
   where
     mk n ret args = do
-      let n' = llvmDefLabel $ fsLit n
+      let n' = fsLit n
           decl = LlvmFunctionDecl n' ExternallyVisible CC_Ccc ret
                                  FixedArgs (tysToParams args) Nothing
       renderLlvm $ ppLlvmFunctionDecl decl
@@ -515,7 +518,10 @@ getGlobalPtr llvmLbl = do
   let mkGlbVar lbl ty = LMGlobalVar lbl (LMPointer ty) Private Nothing Nothing
   case m_ty of
     -- Directly reference if we have seen it already
-    Just ty -> return $ mkGlbVar (llvmDefLabel llvmLbl) ty Global
+    Just ty -> do
+      if llvmLbl `elem` (map fsLit ["newSpark", "memmove", "memcpy", "memcmp", "memset"])
+        then return $ mkGlbVar (llvmLbl) ty Global
+        else return $ mkGlbVar (llvmDefLabel llvmLbl) ty Global
     -- Otherwise use a forward alias of it
     Nothing -> do
       saveAlias llvmLbl


=====================================
rts/linker/Elf.c
=====================================
@@ -780,7 +780,12 @@ ocGetNames_ELF ( ObjectCode* oc )
           else if (!oc->imageMapped || size < getPageSize() / 3) {
               bool executable = kind == SECTIONKIND_CODE_OR_RODATA;
               m32_allocator *allocator = executable ? oc->rx_m32 : oc->rw_m32;
-              start = m32_alloc(allocator, size, 8);
+              // align on 16 bytes. The reason being that llvm will emit see
+              // paddq statements for x86_64 under optimisation and load from
+              // RODATA sections. Specifically .rodata.cst16. However we don't
+              // handle the cst part in any way what so ever, so 16 seems
+              // better than 8.
+              start = m32_alloc(allocator, size, 16);
               if (start == NULL) goto fail;
               memcpy(start, oc->image + offset, size);
               alloc = SECTION_M32;
@@ -915,7 +920,7 @@ ocGetNames_ELF ( ObjectCode* oc )
                    symbol->addr = (SymbolAddr*)(
                            (intptr_t) oc->sections[secno].start +
                            (intptr_t) symbol->elf_sym->st_value);
-
+                   ASSERT(symbol->addr != 0x0);
                    if (ELF_ST_BIND(symbol->elf_sym->st_info) == STB_LOCAL) {
                        isLocal = true;
                        isWeak = false;
@@ -1842,6 +1847,7 @@ ocResolve_ELF ( ObjectCode* oc )
 #endif
                 ASSERT(symbol->elf_sym->st_name == 0);
                 ASSERT(symbol->elf_sym->st_value == 0);
+                ASSERT(0x0 != oc->sections[ secno ].start);
                 symbol->addr = oc->sections[ secno ].start;
             }
         }
@@ -1915,6 +1921,7 @@ int ocRunInit_ELF( ObjectCode *oc )
          init_start = (init_t*)init_startC;
          init_end = (init_t*)(init_startC + shdr[i].sh_size);
          for (init = init_start; init < init_end; init++) {
+            ASSERT(0x0 != *init);
             (*init)(argc, argv, envv);
          }
       }


=====================================
rts/linker/elf_reloc_aarch64.c
=====================================
@@ -297,7 +297,7 @@ relocateObjectCodeAarch64(ObjectCode * oc) {
                                relTab->sectionHeader->sh_link,
                                ELF64_R_SYM((Elf64_Xword)rel->r_info));
 
-            assert(symbol != NULL);
+            assert(0x0 != symbol);
 
             /* decode implicit addend */
             int64_t addend = decodeAddendAarch64(targetSection, rel);
@@ -324,6 +324,7 @@ relocateObjectCodeAarch64(ObjectCode * oc) {
                                ELF64_R_SYM((Elf64_Xword)rel->r_info));
 
             assert(0x0 != symbol);
+            assert(0x0 != symbol->addr);
 
             /* take explicit addend */
             int64_t addend = rel->r_addend;


=====================================
testsuite/driver/testlib.py
=====================================
@@ -2189,6 +2189,13 @@ def normalise_errmsg(s: str) -> str:
         s = re.sub('Failed to remove file (.*); error= (.*)$', '', s)
         s = re.sub('DeleteFile "(.+)": permission denied \(Access is denied\.\)(.*)$', '', s)
 
+    # filter out unsupported GNU_PROPERTY_TYPE (5), which is emitted by LLVM10
+    # and not understood by older binutils (ar, ranlib, ...)
+    s = modify_lines(s, lambda l: re.sub('^(.+)warning: (.+): unsupported GNU_PROPERTY_TYPE \(5\) type: 0xc000000(.*)$', '', l))
+
+    # filter out nix garbage, that just keeps on showing up as errors on darwin
+    s = modify_lines(s, lambda l: re.sub('^(.+)\.dylib, ignoring unexpected dylib file$','', l))
+
     return s
 
 # normalise a .prof file, so that we can reasonably compare it against
@@ -2259,6 +2266,9 @@ def normalise_output( s: str ) -> str:
     s = re.sub('([^\\s])\\.exe', '\\1', s)
     s = normalise_callstacks(s)
     s = normalise_type_reps(s)
+    # ghci outputs are pretty unstable with -fexternal-dynamic-refs, which is
+    # requires for -fPIC
+    s = re.sub('  -fexternal-dynamic-refs\n','',s)
     return s
 
 def normalise_asm( s: str ) -> str:



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/a3e195ae70c569e1a140e22175220d28d8be35c0

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/a3e195ae70c569e1a140e22175220d28d8be35c0
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20201124/ac6d020f/attachment-0001.html>