Skip to content
Snippets Groups Projects
Forked from Glasgow Haskell Compiler / GHC
Loading
  • Artem Pyanykh's avatar
    0d31ccdd
    [linker, macho] Don't map/allocate zero size sections and segments · 0d31ccdd
    Artem Pyanykh authored and Marge Bot's avatar Marge Bot committed
    Zero size sections are common even during regular build on MacOS. For
    instance:
    
    ```
    $ ar -xv libHSghc-prim-0.6.1.a longlong.o
    $ otool -l longlong.o
    longlong.o:
    Mach header
          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
     0xfeedfacf 16777223          3  0x00           1     2        176 0x00002000
    Load command 0
          cmd LC_SEGMENT_64
      cmdsize 152
      segname
       vmaddr 0x0000000000000000
       vmsize 0x0000000000000000 <-- segment size = 0
      fileoff 208
     filesize 0
      maxprot 0x00000007
     initprot 0x00000007
       nsects 1
        flags 0x0
    Section
      sectname __text
       segname __TEXT
          addr 0x0000000000000000
          size 0x0000000000000000 <-- section size = 0
        offset 208
         align 2^0 (1)
        reloff 0
        nreloc 0
         flags 0x80000000
     reserved1 0
     reserved2 0
           cmd LC_BUILD_VERSION
       cmdsize 24
      platform macos
           sdk 10.14
         minos 10.14
        ntools 0
    ```
    
    The issue of `mmap`ing 0 bytes was resolved in !1050, but the problem
    remained. These 0 size segments and sections were still allocated in
    object code, which lead to failed `ASSERT(size > 0)` in
    `addProddableBlock` further down the road.
    
    With this change zero size segments **and** sections are not
    mapped/allocated at all.
    
    Test plan:
    
    1. Build statically linked GHC.
    
    2. Run `ghc --interactive`. Observe that REPL loads
    successfully (which was not the case before).
    
    3. Load several more compiled hs files into repl. No failures.
    0d31ccdd
    History
    [linker, macho] Don't map/allocate zero size sections and segments
    Artem Pyanykh authored and Marge Bot's avatar Marge Bot committed
    Zero size sections are common even during regular build on MacOS. For
    instance:
    
    ```
    $ ar -xv libHSghc-prim-0.6.1.a longlong.o
    $ otool -l longlong.o
    longlong.o:
    Mach header
          magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
     0xfeedfacf 16777223          3  0x00           1     2        176 0x00002000
    Load command 0
          cmd LC_SEGMENT_64
      cmdsize 152
      segname
       vmaddr 0x0000000000000000
       vmsize 0x0000000000000000 <-- segment size = 0
      fileoff 208
     filesize 0
      maxprot 0x00000007
     initprot 0x00000007
       nsects 1
        flags 0x0
    Section
      sectname __text
       segname __TEXT
          addr 0x0000000000000000
          size 0x0000000000000000 <-- section size = 0
        offset 208
         align 2^0 (1)
        reloff 0
        nreloc 0
         flags 0x80000000
     reserved1 0
     reserved2 0
           cmd LC_BUILD_VERSION
       cmdsize 24
      platform macos
           sdk 10.14
         minos 10.14
        ntools 0
    ```
    
    The issue of `mmap`ing 0 bytes was resolved in !1050, but the problem
    remained. These 0 size segments and sections were still allocated in
    object code, which lead to failed `ASSERT(size > 0)` in
    `addProddableBlock` further down the road.
    
    With this change zero size segments **and** sections are not
    mapped/allocated at all.
    
    Test plan:
    
    1. Build statically linked GHC.
    
    2. Run `ghc --interactive`. Observe that REPL loads
    successfully (which was not the case before).
    
    3. Load several more compiled hs files into repl. No failures.
Code owners