[PATCH] D29315: MCMacho: Allow __thread_ptr section after dwarf sections

[Jim Grosbach via Phabricator via llvm-commits]

grosbach added a comment.

In https://reviews.llvm.org/D29315#662038, @MatzeB wrote:

> In https://reviews.llvm.org/D29315#661848, @grosbach wrote:
>
> > Nothing that can have relocations or fixups to or from it should go after the debug info. This patch doesn't seem right to me.
>
>
> What's the motivation for this rule? Less work when `strip`ing a binary?
>
> Also we do allow the `__DATA/__nl_symbol_ptr` section after the dwarf sections today it seems, shouldn't `__DATA/__thread_ptr` behave very similar?


The main thing is that debug info can get so large that putting it between things results in relocations being out of range of what the file format can represent. So we put all the stuff than can reference each other w/ relocations up front next to one another.  __TEXT relocations in particular due to the references being start-of-file relative offsets. It might be OK(ish) for __DATA? That would line up with various commit messages. That we're tripping the assert() might imply it's not? Worth exploring a bit to be sure. Debugging when this stuff goes wrong is unpleasant.

For some history on that part, see r231898 and r232842.



================
Comment at: test/MC/MachO/ARM/no-tls-assert.ll:2
+; RUN: llc -filetype=obj -o /dev/null %s
+; This should not trigger the "Creating regular section after DWARF" assert.
+target triple = "thumbv7-apple-ios9.0.0"
----------------
MatzeB wrote:
> grosbach wrote:
> > MatzeB wrote:
> > > aprantl wrote:
> > > > It would be better to check the ASM output for the section switch commands. Otherwise this test succeeds even if llc is symlinked to /bin/true ;-)
> > > The assert would not trigger when writing assembly, but I can probably pipe the output through llvm-objdump.
> > That's concerning. What is the assembler doing differently? Any output from the object emitter directly from the compiler should be reproducible when going through assembly.
> The assert is only in MCMachoStreamer. I assume when writing an assembly file the order in which we see the `.section` directives doesn't influence the order of the sections in the object file? That would explain why we wouldn't need to enforce the order for assembly.
Barring something explicitly overriding the behaviour, the order of the .section directives is exactly what determines the order in the object file. That's why a long time ago in a toolchain far, far away we put a preamble in the .s files w/ a bunch of .section directives.  That changed with r232842.

Even with that, however, the section ordering should be coming out the same from a .s file. That's a different quirk and needs understood.


Repository:
  rL LLVM

https://reviews.llvm.org/D29315