<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 11:39 AM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
On Jan 30, 2015, at 6:04 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
> The big drawback is that I can no longer influence the order in which the sections are emitted, which turns out to be a problem for COFF.<br>
> Although COFF sections are marked with the correct alignment characteristics, they are not actually emitted aligned on disk. This is hopefully just a bug in our COFF backend. Since the DWARF sections are of arbitrary size and come before the serialized AST, this messes up the alignment for OnDiskHashTable. Until I figure out a solution for this problem, I’ve disabled module debug info ouput for COFF.<br>
<br>
[CC’ing a bunch of people who recently touched the COFF streamer.]<br>
<br>
I’m creating a new section via a global variable like this:<br>
<br>
    auto *ASTSym = new llvm::GlobalVariable(<br>
        *M, Ty, /*constant*/ true, llvm::GlobalVariable::InternalLinkage,<br>
        Data, "__clang_ast");<br>
    ASTSym->setAlignment(8);<br>
    ASTSym->setSection("clangast”);<br>
<br>
and llvm-readobj tells me it comes out as:<br>
<br>
  Section {<br>
    Number: 12<br>
    Name: clangast (63 6C 61 6E 67 61 73 74)<br>
    VirtualSize: 0x0<br>
    VirtualAddress: 0x0<br>
    RawDataSize: 148992<br>
    PointerToRawData: 0x4FB   <-- 1275<br>
    PointerToRelocations: 0x0<br>
    PointerToLineNumbers: 0x0<br>
    RelocationCount: 0<br>
    LineNumberCount: 0<br>
    Characteristics [ (0x40400040)<br>
      IMAGE_SCN_ALIGN_8BYTES (0x400000)<br>
      IMAGE_SCN_CNT_INITIALIZED_DATA (0x40)<br>
      IMAGE_SCN_MEM_READ (0x40000000)<br>
    ]<br>
  }<br>
<br>
or in assembly:<br>
<br>
  ...<br>
  Lsection_debug_loc:<br>
        .section        .debug_ranges,"r"<br>
  Ldebug_range:<br>
        .section        clangast,"dr"<br>
        .align  8<br>
  ___clang_ast:<br>
  ...<br>
<br>
Even though the section has the IMAGE_SCN_ALIGN_8BYTES characteristic and the symbol is aligned, the ___clang_ast symbol is still emitted to disk immediately following the previous section and thus ends up at a random unaligned address. This breaks OnDiskHashtable when the object file is mmapped from disk later.<br>
<br>
Am I using it wrong or is this a bug in the coff backend?<br></blockquote><div><br></div><div>I don't think this is a bug.  Here is the relevant text from the COFF specification for the PointerToRawData field:</div><div><div>For executable images, this must be a multiple of FileAlignment from the optional header.</div><div>For object files, the value should be aligned on a 4byte boundary for best performance.</div></div><div><br></div><div>We aren't required to align the section contents in object files.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Any ideas how to fix it?<br></blockquote><div><br></div><div>Nothing would stop us from having a little padding before the start of the section contents.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
-- adrian</font></span></blockquote></div><br></div></div>