[lld] r244691 - COFF: Align sections to 512-byte boundaries on disk.

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 9 19:17:48 PDT 2015 

I got a chance to look at this today in RamMap. Looks like they do have
some crazy hack in the kernel to handle images specially:
http://i.imgur.com/BeDov07.png
They have a special "image" flag column to indicate this.

-- Sean Silva

On Fri, Aug 14, 2015 at 1:19 AM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> On Thu, Aug 13, 2015 at 10:53 PM, Rui Ueyama <ruiu at google.com> wrote:
>
>> On Fri, Aug 14, 2015 at 8:04 AM, Sean Silva <chisophugis at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Aug 13, 2015 at 12:51 AM, Rui Ueyama <ruiu at google.com> wrote:
>>>
>>>> I think I do understand how the paging mechanism works. :)  We are
>>>> talking about different things. My question is why you think a file offset
>>>> must be at a 4K boundary in order to map it efficiently to memory. To me
>>>> you seems to be claiming that mmap(0, /*length*/4096, PROT_READ|PROT_EXEC,
>>>> 0, SomeFD, /*file offset*/5120) is much inefficient than mmap(0,
>>>> /*length*/4096, PROT_READ|PROT_EXEC, 0, SomeFD, /*file
>>>> offset*/4096) because of the file offset of the former mmap call is not a
>>>> multiple of 4096. And I'm saying that that's not true.
>>>>
>>>
>>>
>>> The paging layer generally has the file already in physical memory
>>> before you ask it to map it. When it originally read the file off disk, how
>>> would it know what alignment the file should have in physical memory? The
>>> reality is that the alignment in the file is the alignment in physical
>>> memory. If the paging system had to be aware of having different parts of
>>> the file mapped in at arbitrary alignments it would be much more
>>> complicated (in practice, it will either be a hard error, or will force the
>>> kernel to explicitly make a copy, but the paging system won't do this
>>> automatically).
>>>
>>
>> The loader is able to (and I presume it does) read only the header of an
>> executable first and then map each sections to memory. I don't think that
>> the entire executables files are "generally" already mapped to memory.
>>
>
> I say "generally" because the loader cannot know or not (layering
> violation in the kernel).
>
>
>> Executable files are usually read only by the loader, and as long as the
>> loader is consistent in how it maps each section to memory, no memcpy is
>> needed.
>>
>
> It would require a pretty serious layering violation for something as
> high-level as the loader to control at what offset modulo the page size a
> piece of a file is read into. It would require reaching through so many
> layers of the kernel in order for the loader to control that. In both Linux
> and FreeBSD (as examples of something in general), there is simply no API
> for mapping files that operates at sub-page granularity. In Linux vm_mmap
> literally rejects anything that is not page aligned (
> http://lxr.free-electrons.com/source/mm/util.c#L306), and immediately
> calls into vm_mmap_pgoff which operates in terms of pages only. In FreeBSD,
> in the link I gave you can see that the copying process is external to the
> virtual memory system / fs -- the loader has to do it itself.
>
> Like I said, it is possible for Windows to have a hack to do this. But it
> seems unlikely since fixing the linker is so much easier. I can believe
> that link.exe might set the FileAlignment to 512 bytes, but surely it must
> be actually page aligning the sections in the file (which is correct to do
> with a setting of FileAlignment == 512).
>
> -- Sean Silva
>
>
>>
>>
>>> Also, keep in mind that 512 byte "sector size" has almost nothing to do
>>> with how modern kernels/hardware do IO. It is a historical thing.
>>>
>>> -- Sean Silva
>>>
>>>
>>>
>>>>
>>>> On Thu, Aug 13, 2015 at 4:10 PM, Sean Silva <chisophugis at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 12, 2015 at 10:59 PM, Rui Ueyama <ruiu at google.com> wrote:
>>>>>
>>>>>> What I don't understand is that why the offset from the beginning of
>>>>>> the file must be multiple of page size in order to avoid full copy. Windows
>>>>>> requires all sections to be aligned at least 4K in memory and 512 bytes on
>>>>>> file, and I don't see any problem there.
>>>>>>
>>>>>> Let's say we have two sections, A and B, whose sizes are 1024B and
>>>>>> 4096B, respectively. We also assume that A's offset from the beginning of
>>>>>> file is 4096, and B's 5120. The loader can map offset 4096 to 8192 of the
>>>>>> file to some page, and 5120 to 9216 to other page. Why can't that?
>>>>>>
>>>>>
>>>>> From the kernel's perspective of mapping memory (on x86), memory is
>>>>> divided into aligned 4K pieces. 5120 % 4096 == 1024, so in order to map it
>>>>> at an address that is 4K aligned, it must do a full memmove in order to
>>>>> move all the memory by 1024 bytes so that it is 4K aligned. This image
>>>>> maybe helps to understand how a 32-bit x86 CPU understands a virtual memory
>>>>> address:
>>>>> https://upload.wikimedia.org/wikipedia/commons/8/8e/X86_Paging_4K.svg
>>>>>
>>>>> IIRC the resources I learned from are:
>>>>>
>>>>> http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory/
>>>>> http://duartes.org/gustavo/blog/post/the-thing-king/
>>>>> (that web page has many other very, *very* good posts. A list can be
>>>>> seen at: http://duartes.org/gustavo/blog/category/internals/)
>>>>>
>>>>> I think you will find that understanding virtual memory (and TLB) will
>>>>> greatly help you optimize LLD, since many operations in LLD have very high
>>>>> pressure on the virtual memory system.
>>>>>
>>>>> -- Sean Silva
>>>>>
>>>>>
>>>>>>
>>>>>> On Thu, Aug 13, 2015 at 2:44 PM, Sean Silva <chisophugis at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 12, 2015 at 7:17 PM, Rui Ueyama <ruiu at google.com> wrote:
>>>>>>>
>>>>>>>> I didn't test to see if this change ever has a negative impact on
>>>>>>>> memory usage, but my guess is that's very unlikely because this layout is
>>>>>>>> the same as what MSVC linker creates. If this is inefficient, virtually all
>>>>>>>> Windows executables are being suffered by that, which is unlikely. My
>>>>>>>> understanding is that the kernel maps each section separately to a memory
>>>>>>>> address, so file offset of each section can be given independently from
>>>>>>>> other sections.
>>>>>>>>
>>>>>>>
>>>>>>> The mapping is done at the granularity of aligned 4K pages minimum
>>>>>>> (this is just how the x86 hardware page table mechanism works). A piece of
>>>>>>> the file cannot be moved by an amount that is not a multiple of 4K without
>>>>>>> a full copy.
>>>>>>>
>>>>>>> The only way this could (in the usual case) not have a large
>>>>>>> overhead is for the kernel to do a crazy hack like have special paging
>>>>>>> semantics for files that are executables. This means that when LLD finishes
>>>>>>> working on a memory mapped file, if a section is not 4K aligned at least,
>>>>>>> then the kernel has to then do a copy to make the file conform the the
>>>>>>> actual memory layout it needs to have in the paging subsystem.
>>>>>>>
>>>>>>> Or does windows make full copies of sections always? In other words
>>>>>>> processes don't share e.g. readonly text?
>>>>>>>
>>>>>>> In ELF, the offset in the file and the offset in memory are required
>>>>>>> to be congruent modulo the alignment (see the documentation of p_align in
>>>>>>> http://www.sco.com/developers/gabi/latest/ch5.pheader.html),
>>>>>>> precisely to avoid the need to do crazy hacks like this when loading the
>>>>>>> program.
>>>>>>>
>>>>>>> You can see that Linux will reject the binary:
>>>>>>> http://lxr.free-electrons.com/source/fs/binfmt_elf.c#L664
>>>>>>> (load_elf_binary)
>>>>>>> -> http://lxr.free-electrons.com/source/fs/binfmt_elf.c#L336
>>>>>>> (elf_map)
>>>>>>> -> http://lxr.free-electrons.com/source/mm/util.c#L306 (vm_mmap)
>>>>>>> Notice:
>>>>>>> 312         if (unlikely(offset & ~PAGE_MASK))
>>>>>>> 313                 return -EINVAL;
>>>>>>>
>>>>>>> FreeBSD is more lenient, but you can see that the kernel does not
>>>>>>> like the situation when this is violated:
>>>>>>>
>>>>>>> http://src.illumos.org/source/xref/freebsd-head/sys/kern/imgact_elf.c#593
>>>>>>> (__elfN(load_file))
>>>>>>> -->
>>>>>>> http://src.illumos.org/source/xref/freebsd-head/sys/kern/imgact_elf.c#467
>>>>>>> (__elfN(load_section))
>>>>>>> -->
>>>>>>> http://src.illumos.org/source/xref/freebsd-head/sys/kern/imgact_elf.c#398
>>>>>>> (__elfN(map_insert))
>>>>>>> 423 /*
>>>>>>> 424 * The mapping is not page aligned. This means we have
>>>>>>> 425 * to copy the data. Sigh.
>>>>>>> 426 */
>>>>>>>
>>>>>>> -- Sean Silva
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Aug 12, 2015 at 5:31 PM, Sean Silva <chisophugis at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Aug 11, 2015 at 4:09 PM, Rui Ueyama via llvm-commits <
>>>>>>>>> llvm-commits at lists.llvm.org> wrote:
>>>>>>>>>
>>>>>>>>>> Author: ruiu
>>>>>>>>>> Date: Tue Aug 11 18:09:00 2015
>>>>>>>>>> New Revision: 244691
>>>>>>>>>>
>>>>>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=244691&view=rev
>>>>>>>>>> Log:
>>>>>>>>>> COFF: Align sections to 512-byte boundaries on disk.
>>>>>>>>>>
>>>>>>>>>> Sections must start at page boundaries in memory, but they
>>>>>>>>>> can be aligned to sector boundaries (512-bytes) on disk.
>>>>>>>>>> We aligned them to 4096-byte boundaries even on disk, so we
>>>>>>>>>> wasted disk space a bit.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This will likely force the kernel to copy or otherwise do
>>>>>>>>> unnecessary work when loading. Are you sure that isn't happening? The
>>>>>>>>> kernel ideally wants to just create a couple page table entries. But if it
>>>>>>>>> needs to move things around at <4K granularity to make them properly
>>>>>>>>> aligned to their load address when loading (like this patch I think causes)
>>>>>>>>> then it will need to do copies.
>>>>>>>>>
>>>>>>>>> This can likely be checked by looking for an increase in real
>>>>>>>>> memory usage for the system when the new binaries are loaded (vs. the old
>>>>>>>>> page-aligned ones), since the kernel will have a copy sitting in page cache
>>>>>>>>> and a copy for alignment mapped into the process address space;
>>>>>>>>> alternatively, you can check for the slowdown from the kernel copies when
>>>>>>>>> faulting the memory into the process's address space (or (less likely) it
>>>>>>>>> may do the copies eagerly which should be easy to measure too).
>>>>>>>>>
>>>>>>>>> -- Sean Silva
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Modified:
>>>>>>>>>>     lld/trunk/COFF/Writer.cpp
>>>>>>>>>>     lld/trunk/test/COFF/baserel.test
>>>>>>>>>>     lld/trunk/test/COFF/hello32.test
>>>>>>>>>>
>>>>>>>>>> Modified: lld/trunk/COFF/Writer.cpp
>>>>>>>>>> URL:
>>>>>>>>>> http://llvm.org/viewvc/llvm-project/lld/trunk/COFF/Writer.cpp?rev=244691&r1=244690&r2=244691&view=diff
>>>>>>>>>>
>>>>>>>>>> ==============================================================================
>>>>>>>>>> --- lld/trunk/COFF/Writer.cpp (original)
>>>>>>>>>> +++ lld/trunk/COFF/Writer.cpp Tue Aug 11 18:09:00 2015
>>>>>>>>>> @@ -37,8 +37,7 @@ using namespace lld;
>>>>>>>>>>  using namespace lld::coff;
>>>>>>>>>>
>>>>>>>>>>  static const int PageSize = 4096;
>>>>>>>>>> -static const int FileAlignment = 512;
>>>>>>>>>> -static const int SectionAlignment = 4096;
>>>>>>>>>> +static const int SectorSize = 512;
>>>>>>>>>>  static const int DOSStubSize = 64;
>>>>>>>>>>  static const int NumberfOfDataDirectory = 16;
>>>>>>>>>>
>>>>>>>>>> @@ -174,7 +173,7 @@ void OutputSection::addChunk(Chunk *C) {
>>>>>>>>>>    Off += C->getSize();
>>>>>>>>>>    Header.VirtualSize = Off;
>>>>>>>>>>    if (C->hasData())
>>>>>>>>>> -    Header.SizeOfRawData = RoundUpToAlignment(Off,
>>>>>>>>>> FileAlignment);
>>>>>>>>>> +    Header.SizeOfRawData = RoundUpToAlignment(Off, SectorSize);
>>>>>>>>>>  }
>>>>>>>>>>
>>>>>>>>>>  void OutputSection::addPermissions(uint32_t C) {
>>>>>>>>>> @@ -507,15 +506,14 @@ void Writer::createSymbolAndStringTable(
>>>>>>>>>>    // We position the symbol table to be adjacent to the end of
>>>>>>>>>> the last section.
>>>>>>>>>>    uint64_t FileOff =
>>>>>>>>>>        LastSection->getFileOff() +
>>>>>>>>>> -      RoundUpToAlignment(LastSection->getRawSize(),
>>>>>>>>>> FileAlignment);
>>>>>>>>>> +      RoundUpToAlignment(LastSection->getRawSize(), SectorSize);
>>>>>>>>>>    if (!OutputSymtab.empty()) {
>>>>>>>>>>      PointerToSymbolTable = FileOff;
>>>>>>>>>>      FileOff += OutputSymtab.size() * sizeof(coff_symbol16);
>>>>>>>>>>    }
>>>>>>>>>>    if (!Strtab.empty())
>>>>>>>>>>      FileOff += Strtab.size() + 4;
>>>>>>>>>> -  FileSize = SizeOfHeaders +
>>>>>>>>>> -             RoundUpToAlignment(FileOff - SizeOfHeaders,
>>>>>>>>>> FileAlignment);
>>>>>>>>>> +  FileSize = RoundUpToAlignment(FileOff, SectorSize);
>>>>>>>>>>  }
>>>>>>>>>>
>>>>>>>>>>  // Visits all sections to assign incremental, non-overlapping
>>>>>>>>>> RVAs and
>>>>>>>>>> @@ -526,9 +524,9 @@ void Writer::assignAddresses() {
>>>>>>>>>>                    sizeof(coff_section) * OutputSections.size();
>>>>>>>>>>    SizeOfHeaders +=
>>>>>>>>>>        Config->is64() ? sizeof(pe32plus_header) :
>>>>>>>>>> sizeof(pe32_header);
>>>>>>>>>> -  SizeOfHeaders = RoundUpToAlignment(SizeOfHeaders, PageSize);
>>>>>>>>>> +  SizeOfHeaders = RoundUpToAlignment(SizeOfHeaders, SectorSize);
>>>>>>>>>>    uint64_t RVA = 0x1000; // The first page is kept unmapped.
>>>>>>>>>> -  uint64_t FileOff = SizeOfHeaders;
>>>>>>>>>> +  FileSize = SizeOfHeaders;
>>>>>>>>>>    // Move DISCARDABLE (or non-memory-mapped) sections to the end
>>>>>>>>>> of file because
>>>>>>>>>>    // the loader cannot handle holes.
>>>>>>>>>>    std::stable_partition(
>>>>>>>>>> @@ -539,13 +537,11 @@ void Writer::assignAddresses() {
>>>>>>>>>>      if (Sec->getName() == ".reloc")
>>>>>>>>>>        addBaserels(Sec);
>>>>>>>>>>      Sec->setRVA(RVA);
>>>>>>>>>> -    Sec->setFileOffset(FileOff);
>>>>>>>>>> +    Sec->setFileOffset(FileSize);
>>>>>>>>>>      RVA += RoundUpToAlignment(Sec->getVirtualSize(), PageSize);
>>>>>>>>>> -    FileOff += RoundUpToAlignment(Sec->getRawSize(),
>>>>>>>>>> FileAlignment);
>>>>>>>>>> +    FileSize += RoundUpToAlignment(Sec->getRawSize(),
>>>>>>>>>> SectorSize);
>>>>>>>>>>    }
>>>>>>>>>>    SizeOfImage = SizeOfHeaders + RoundUpToAlignment(RVA - 0x1000,
>>>>>>>>>> PageSize);
>>>>>>>>>> -  FileSize = SizeOfHeaders +
>>>>>>>>>> -             RoundUpToAlignment(FileOff - SizeOfHeaders,
>>>>>>>>>> FileAlignment);
>>>>>>>>>>  }
>>>>>>>>>>
>>>>>>>>>>  template <typename PEHeaderTy> void Writer::writeHeader() {
>>>>>>>>>> @@ -584,8 +580,8 @@ template <typename PEHeaderTy> void Writ
>>>>>>>>>>    Buf += sizeof(*PE);
>>>>>>>>>>    PE->Magic = Config->is64() ? PE32Header::PE32_PLUS :
>>>>>>>>>> PE32Header::PE32;
>>>>>>>>>>    PE->ImageBase = Config->ImageBase;
>>>>>>>>>> -  PE->SectionAlignment = SectionAlignment;
>>>>>>>>>> -  PE->FileAlignment = FileAlignment;
>>>>>>>>>> +  PE->SectionAlignment = PageSize;
>>>>>>>>>> +  PE->FileAlignment = SectorSize;
>>>>>>>>>>    PE->MajorImageVersion = Config->MajorImageVersion;
>>>>>>>>>>    PE->MinorImageVersion = Config->MinorImageVersion;
>>>>>>>>>>    PE->MajorOperatingSystemVersion = Config->MajorOSVersion;
>>>>>>>>>>
>>>>>>>>>> Modified: lld/trunk/test/COFF/baserel.test
>>>>>>>>>> URL:
>>>>>>>>>> http://llvm.org/viewvc/llvm-project/lld/trunk/test/COFF/baserel.test?rev=244691&r1=244690&r2=244691&view=diff
>>>>>>>>>>
>>>>>>>>>> ==============================================================================
>>>>>>>>>> --- lld/trunk/test/COFF/baserel.test (original)
>>>>>>>>>> +++ lld/trunk/test/COFF/baserel.test Tue Aug 11 18:09:00 2015
>>>>>>>>>> @@ -61,7 +61,7 @@
>>>>>>>>>>  # BASEREL-HEADER-NEXT: VirtualSize: 0x20
>>>>>>>>>>  # BASEREL-HEADER-NEXT: VirtualAddress: 0x5000
>>>>>>>>>>  # BASEREL-HEADER-NEXT: RawDataSize: 512
>>>>>>>>>> -# BASEREL-HEADER-NEXT: PointerToRawData: 0x1800
>>>>>>>>>> +# BASEREL-HEADER-NEXT: PointerToRawData: 0xC00
>>>>>>>>>>  # BASEREL-HEADER-NEXT: PointerToRelocations: 0x0
>>>>>>>>>>  # BASEREL-HEADER-NEXT: PointerToLineNumbers: 0x0
>>>>>>>>>>  # BASEREL-HEADER-NEXT: RelocationCount: 0
>>>>>>>>>>
>>>>>>>>>> Modified: lld/trunk/test/COFF/hello32.test
>>>>>>>>>> URL:
>>>>>>>>>> http://llvm.org/viewvc/llvm-project/lld/trunk/test/COFF/hello32.test?rev=244691&r1=244690&r2=244691&view=diff
>>>>>>>>>>
>>>>>>>>>> ==============================================================================
>>>>>>>>>> --- lld/trunk/test/COFF/hello32.test (original)
>>>>>>>>>> +++ lld/trunk/test/COFF/hello32.test Tue Aug 11 18:09:00 2015
>>>>>>>>>> @@ -38,8 +38,8 @@ HEADER-NEXT:   MajorImageVersion: 0
>>>>>>>>>>  HEADER-NEXT:   MinorImageVersion: 0
>>>>>>>>>>  HEADER-NEXT:   MajorSubsystemVersion: 6
>>>>>>>>>>  HEADER-NEXT:   MinorSubsystemVersion: 0
>>>>>>>>>> -HEADER-NEXT:   SizeOfImage: 20480
>>>>>>>>>> -HEADER-NEXT:   SizeOfHeaders: 4096
>>>>>>>>>> +HEADER-NEXT:   SizeOfImage: 16896
>>>>>>>>>> +HEADER-NEXT:   SizeOfHeaders: 512
>>>>>>>>>>  HEADER-NEXT:   Subsystem: IMAGE_SUBSYSTEM_WINDOWS_CUI (0x3)
>>>>>>>>>>  HEADER-NEXT:   Characteristics [ (0x8140)
>>>>>>>>>>  HEADER-NEXT:     IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE (0x40)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> llvm-commits mailing list
>>>>>>>>>> llvm-commits at lists.llvm.org
>>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150909/7307d509/attachment.html>

More information about the llvm-commits mailing list