<div dir="ltr"><div class="gmail_extra"><div>On Mon, Apr 8, 2013 at 12:17 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><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"><div class="im">> * SHF_ATOMIZED<br>

>  This is important to be able to be alone for performance reasons. All<br>
> current code can use this without breaking, even if it makes assumptions<br>
> about the ABI. It's just letting the linker know that the compiler did<br>
> what the compiler almost always does, which is give correct symbol sizes.<br>
<br>
</div>This is a weaker statement than you gave previously, where you specified<br>
that it also means relocation addends do not cross symbol boundaries.<br>
I assume you still want the relocation restrictions, which tells the linker<br>
that the symbols define proper atoms.  Having correct sizes all by itself<br>
does not tell you that.</blockquote><div><br></div><div style>I moved this over to SHF_SUBSECTIONS_VIA_SYMBOLS so that SHF_ATOMIZED can be enabled by default.</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">
<div class="im">
> * SHF_SUBSECTIONS_VIA_SYMBOLS<br>
>  Alone this is not very useful. But it's important for SHF_ATOMIZED to be<br>
> not tied to this for compatibility reasons.<br>
<br>
</div>Yeah, I even thought of a use case for atomized-but-not-subsections:<br>
In a code section, if control can fall through from one atom to the next,<br>
obviously the atoms can't be rearranged.  Can happen in hand-coded assembler,<br>
or in a language with alternate entry points to the same function (I think<br>
FORTRAN permits this, of the languages known to use LLVM).<br>
<br>
It is possible you want SHF_SUBSECTIONS_VIA_SYMBOLS to add another constraint<br>
on relocations:<br>
<div class="im"><br>
* If any relocation has a target symbol which is defined in a section with<br>
</div>  this flag set, that symbol must not have type STT_SECTION.<br>
<br>
That is, every relocation targeting this section will use an atom-base<br>
symbol, not .section+N relocations.  My patch does not fully achieve this<br>
effect, some relocations from .debug_info to .text are still in .text+N<br>
form.  My toolchain doesn't care because when we're dead-stripping, we<br>
don't care about .debug_info anyway, but it suggests something slipped<br>
through the cracks that you might care about.<br></blockquote><div><br></div><div style>Yep, this is part of what I was trying to require.</div><div style><br></div><div style>The debug relocations are like this because of how DWARF works. I'll have to look into it more for how to properly solve this. MachO avoids this problem because it doesn't link debug info, so the section offsets are still valid.</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">
<div class="im"><br>
><br>
> * SHF_DEADSTRIP<br>
>  This is important in cases where you care about code size, especially on<br>
> platforms where relaxation can greatly shrink code size, but you still want<br>
> to remove entirely dead sections. This is based on -f{function,data}-sections<br>
> + --gc-sections generating a larger binary in practice than just --gc-sections<br>
> in cases where most code is not dead. It's also important for this to be per<br>
> section instead of a linker flag because not all sections can be removed if<br>
> not referenced. The alternative is keeping a hard coded list of special<br>
> sections in the linker, which is what we do now.<br>
<br>
</div>Just to verify, SHF_DEADSTRIP means the linker can trash the section as a<br>
whole, and SHF_DEADSTRIP+SHF_SUBSECTIONS_VIA_SYMBOLS means the linker can<br>
trash individual subsections.<br></blockquote><div><br></div><div style>Yes.</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">

<br>
<br>
So, getting back to my actual patch, there are two things it would need:<br>
- if you care about relocations from .debug_info following the subsection<br>
  rules, then I need to track down why I still get .text+N for those;<br></blockquote><div><br></div><div style>This is a much larger issue. We can fix it later. Just document it.</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">

- and somehow I'd need to arrange to set these three new section flags on<br>
  the right sections. Seems clear they would not go on all sections...<br></blockquote><div><br></div><div style>SectionKind::is{Text,Data{Rel,RelLocal,NoRel},ReadOnlyWithRel{,Local}}() ?</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">

<br>
Oh, and figure out which bits to use for the new flags, that won't<br>
interfere with anybody else's section-flag bits.<br>
<br>
Thanks,<br>
--paulr<br></blockquote><div><br></div><div style>I'm not sure how to pick which bits LLVM should use. For now we can add some bits to MCSectionELF that backends can use to choose what to emit.</div><div style><br></div>
<div style>We'll also need to add 3 single letter flags for the assembly syntax. atomi(z)e, subsections_(v)ia_symbols, (d)eadstrip?</div><div><br></div><div style>- Michael Spencer </div></div><br></div></div>