<div dir="ltr">Firstly, do you need "main.dsp" defined as an external symbol, or can all external references go via "main"? If the answer is the latter, that will make the solution simpler.<div><div><br></div><div>If only the latter, you will need to make a change to LLVM here: <a href="http://llvm-cs.pcc.me.uk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#650">http://llvm-cs.pcc.me.uk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#650</a></div><div><br></div><div>Basically you would need to add a hook to the TargetLoweringObjectFile class that allows the object format to control how prefix data is emitted. For Mach-O you would emit a label for a dummy internal symbol, followed by the prefix data and then an alt_entry directive for the function symbol. All other object formats would just emit the prefix data.</div><div><br></div><div>Peter</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 6, 2017 at 6:16 PM, Moritz Angermann <span dir="ltr"><<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you Peter!<br>
<br>
That seems to do the trick!<br>
<br>
$ cat test.s<br>
<span class=""> .section __TEXT,__text<br>
.globl _main<br>
<br>
.long 1<br>
_main:<br>
inc %eax<br>
ret<br>
<br>
</span> .alt_entry _main<br>
_main.dsp = _main-4<br>
<br>
.subsections_via_symbols<br>
<br>
<br>
$ clang test.s -dead_strip<br>
<span class="">$ otool -vVtdj a.out<br>
a.out:<br>
</span><span class="">_main.dsp:<br>
0000000100000fb1 01 00 addl %eax, (%rax)<br>
0000000100000fb3 00 00 addb %al, (%rax)<br>
_main:<br>
0000000100000fb5 ff c0 incl %eax<br>
0000000100000fb7 c3 retq<br>
<br>
<br>
<br>
</span>However, now I need to figure out how to generate this from<br>
llvm via an alias.<br>
<br>
@.str = private unnamed_addr constant [8 x i8] c"p = %d\0A\00", align 1<br>
<br>
%struct.prefix = type { i32 }<br>
@main.dsp = alias i32, i32* getelementptr (%struct.prefix, %struct.prefix* bitcast (i32 ()* @main to %struct.prefix*), i32 -1, i32 0)<br>
<br>
declare i32 @printf(i8*, ...)<br>
<br>
define i32 @main() prefix %struct.prefix { i32 123 } {<br>
<span class=""> %main = bitcast i32 ()* @main to i32*<br>
</span><span class=""> %prefix_ptr = getelementptr inbounds i32, i32* %main, i32 -1<br>
</span><span class=""> %prefix_val = load i32, i32* %prefix_ptr<br>
</span> %ret = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str, i32 0, i32 0), i32 %prefix_val)<br>
ret i32 0<br>
}<br>
<br>
<br>
generates the following for me:<br>
<br>
.section __TEXT,__text,regular,pure_<wbr>instructions<br>
.macosx_version_min 10, 12<br>
.globl _main<br>
.p2align 4, 0x90<br>
.long 123 ## @main<br>
## 0x7b<br>
_main:<br>
.cfi_startproc<br>
## BB#0:<br>
pushq %rax<br>
Ltmp0:<br>
.cfi_def_cfa_offset 16<br>
movl _main-4(%rip), %esi<br>
leaq L_.str(%rip), %rdi<br>
xorl %eax, %eax<br>
callq _printf<br>
xorl %eax, %eax<br>
popq %rcx<br>
retq<br>
.cfi_endproc<br>
<br>
.section __TEXT,__cstring,cstring_<wbr>literals<br>
L_.str: ## @.str<br>
.asciz "p = %d\n"<br>
<br>
<br>
.globl _main.dsp<br>
<span class=""> .alt_entry _main.dsp<br>
_main.dsp = _main-4<br>
.subsections_via_symbols<br>
<br>
</span>any ideas how to get the .alt_entry right?<br>
<br>
Cheers,<br>
Moritz<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Mar 7, 2017, at 10:02 AM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br>
><br>
> On Mon, Mar 6, 2017 at 5:54 PM, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com">moritz.angermann@gmail.com</a>> wrote:<br>
> Hi Peter,<br>
><br>
> I’ve just experimented with this a bit:<br>
><br>
> Say we would end up with the following assembly:<br>
><br>
> .section __TEXT,__text<br>
> .globl _main<br>
><br>
> .long 1<br>
> _main:<br>
> inc %eax<br>
> ret<br>
><br>
> .globl _main.dsp<br>
> .alt_entry _main.dsp<br>
><br>
> What happens if you try ".alt_entry _main" instead? The alt_entry is supposed to be bound to the atom appearing *before* it.<br>
><br>
> _main.dsp = _main-4<br>
><br>
> .subsections_via_symbols<br>
><br>
> (e.g. we inject the .alt_entry after the fact, pointing to the start of the prefix data)<br>
><br>
> this will yield:<br>
><br>
> $ clang test.s -dead_strip<br>
> ld: warning: N_ALT_ENTRY bit set on first atom in section __TEXT/__text<br>
><br>
> And the prefix data will be stripped again.<br>
><br>
> E.g. what you end up getting is:<br>
><br>
> $ otool -vVtdj a.out<br>
> a.out:<br>
> _main:<br>
> 0000000100000fb5 ff c0 incl %eax<br>
> 0000000100000fb7 c3 retq<br>
><br>
> instead of what we’d like to get:<br>
><br>
> otool -vVtdj a.out<br>
> a.out:<br>
> _main.dsp:<br>
> 0000000100000fb1 01 00 addl %eax, (%rax)<br>
> 0000000100000fb3 00 00 addb %al, (%rax)<br>
> _main:<br>
> 0000000100000fb5 ff c0 incl %eax<br>
> 0000000100000fb7 c3 retq<br>
><br>
> .alt_entry’s are not dead_strip protected, and this makes sense I guess, as if the alt_entry is never<br>
> actually called visibly from anywhere, it’s probably not needed. However there is the .no_daed_strip<br>
> directive. Thus if we graft this slightly different:<br>
><br>
> .section __TEXT,__text<br>
> .globl _main<br>
><br>
> .long 1<br>
> _main:<br>
> inc %eax<br>
> ret<br>
><br>
> .no_dead_strip _main.dsp<br>
> .alt_entry _main.dsp<br>
> _main.dsp = _main-4<br>
><br>
> .subsections_via_symbols<br>
><br>
> we still get a warning, but it won’t get stripped. At that point however, we don’t need the .alt_entry<br>
> anymore (and can drop the warning).<br>
><br>
> Thus, I’d propose that for functions with prefix_data, a second symbol with .no_dead_strip is emitted<br>
> for the prefix data entry point.<br>
><br>
> I don't think that is sufficient. I believe that the linker is allowed to move the function away from the prefix data even if the function is not dead stripped.<br>
><br>
> Peter<br>
><br>
><br>
> Cheers,<br>
> Moritz<br>
><br>
><br>
> > On Mar 7, 2017, at 3:35 AM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br>
> ><br>
> > That is in theory what omitting the .subsections_via_symbols directive is supposed to do, but in an experiment I ran a year or two ago I found that the Mach-O linker was still dead stripping on symbol boundaries with this directive omitted.<br>
> ><br>
> > In any case, a more precise approach has more recently (~a few months ago) become possible. There is a relatively new asm directive called .altentry that, as I understand it, tells the linker to disregard a given symbol as a section boundary (LLVM already uses this for aliases pointing into the middle of a global). So what you would do is to use .altentry on the function symbol, with an internal symbol appearing before the prefix data to ensure that it is not considered part of the body of the previous function.<br>
> ><br>
> > Peter<br>
> ><br>
> > On Mon, Mar 6, 2017 at 11:19 AM, James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> > AFAIK, this cannot actually work on Apple platforms, because its object file format (Mach-O) doesn't use sections to determine the ranges of code/data to keep together, but instead _infers_ boundaries based on the range between global symbols in the symbol table.<br>
> ><br>
> > So, the symbol pointing to the beginning of @main *necessarily* makes that be a section boundary.<br>
> ><br>
> > I think the best that could be done in LLVM is to not emit the ".subsections_via_symbols" asm directive (effectively disabling dead stripping on that object) if any prefix data exists. Currently it emits that flag unconditionally for MachO.<br>
> ><br>
> > On Mon, Mar 6, 2017 at 4:40 AM, Moritz Angermann via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > I just came across a rather annoying behavior with llvm 3.9. Assuming the following<br>
> > samle code in test.ll:<br>
> ><br>
> > ; Lets have some global int x = 4<br>
> > @x = global i32 10, align 4<br>
> > ; and two strings "p = %d\n" for the prefix data,<br>
> > ; as well as "x = %d\n" to print the (global) x value.<br>
> > @.str = private unnamed_addr constant [8 x i8] c"x = %d\0A\00", align 1<br>
> > @.str2 = private unnamed_addr constant [8 x i8] c"p = %d\0A\00", align 1<br>
> ><br>
> > ; declare printf, we'll use this later for printf style debugging.<br>
> > declare i32 @printf(i8*, ...)<br>
> ><br>
> > ; define a main function.<br>
> > define i32 @main() prefix i32 123 {<br>
> > ; obtain a i32 pointer to the main function.<br>
> > ; the prefix data is right before that pointer.<br>
> > %main = bitcast i32 ()* @main to i32*<br>
> ><br>
> > ; use the gep, to cmpute the start of the prefix data.<br>
> > %prefix_ptr = getelementptr inbounds i32, i32* %main, i32 -1<br>
> > ; and load it.<br>
> > %prefix_val = load i32, i32* %prefix_ptr<br>
> ><br>
> > ; print that value.<br>
> > %ret = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str2, i32 0, i32 0), i32 %prefix_val)<br>
> ><br>
> > ; similarly let's do the same with the global x.<br>
> > %1 = alloca i32, align 4<br>
> > store i32 0, i32* %1, align 4<br>
> > %2 = load i32, i32* @x, align 4<br>
> > %3 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str, i32 0, i32 0), i32 %2)<br>
> > ret i32 0<br>
> > }<br>
> ><br>
> > gives the following result (expected)<br>
> ><br>
> > $ clang test.ll<br>
> > $ ./a.out<br>
> > p = 123<br>
> > x = 10<br>
> ><br>
> > however, with -dead_strip on macOS, we see the following:<br>
> ><br>
> > $ clang test.ll -dead_strip<br>
> > $ ./a.out<br>
> > p = 0<br>
> > x = 10<br>
> ><br>
> > Thus I believe we are incorrectly stripping prefix data when linking with -dead_strip on macOS.<br>
> ><br>
> > As I do not have a bugzilla account, and hence cannot post this as a proper bug report.<br>
> ><br>
> > Cheers,<br>
> > Moritz<br>
> > ______________________________<wbr>_________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > --<br>
> > Peter<br>
><br>
><br>
><br>
><br>
> --<br>
> --<br>
> Peter<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div>