<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 6, 2017, at 7:56 PM, James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div dir="ltr" class="">Oh, that's great that it's possible to implement properly, now. Does it actually work for <div class=""><br class=""></div><div class="">It'd be cool if LLVM hooked up its generic section handling support to this feature now, so that the only global symbols that *didn't* get marked as .alt_entry were those at the beginning of what llvm would consider sections.</div><div class=""><br class=""></div><div class=""></div><div class="">Then apple platforms could behave sanely, like all other platforms do, only with -f{function,data}-sections defaulted to on instead of off.</div></div></div></div></blockquote><div><br class=""></div><div>What is the advantage of not using -f{function,data}-sections? (i.e. what isn’t sane about it?)</div><div><br class=""></div><div>I’m asking because I was told the only reason not to use it all the time on ELF is that it makes intermediate object files larger.</div><div><br class=""></div><div>Thanks,</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">(That is, if you specify -fno-function-sections -fno-data-sections, it could mark nearly *everything* as .alt_entry -- except the first symbol in the object file)</div><div class=""><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Mar 6, 2017 at 2:35 PM, Peter Collingbourne <span dir="ltr" class=""><<a href="mailto:peter@pcc.me.uk" target="_blank" class="">peter@pcc.me.uk</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Peter</div></div><div class="gmail_extra"><div class=""><div class="m_37750768197969627h5"><br class=""><div class="gmail_quote">On Mon, Mar 6, 2017 at 11:19 AM, James Y Knight via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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.<div class=""><div class=""><br class=""></div><div class="">So, the symbol pointing to the beginning of @main *necessarily* makes that be a section boundary.</div></div><div class=""><br class=""></div><div class="">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.</div></div><div class="m_37750768197969627m_-2098018759435103914HOEnZb"><div class="m_37750768197969627m_-2098018759435103914h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Mar 6, 2017 at 4:40 AM, Moritz Angermann via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<br class="">
I just came across a rather annoying behavior with llvm 3.9. Assuming the following<br class="">
samle code in test.ll:<br class="">
<br class="">
; Lets have some global int x = 4<br class="">
@x = global i32 10, align 4<br class="">
; and two strings "p = %d\n" for the prefix data,<br class="">
; as well as "x = %d\n" to print the (global) x value.<br class="">
@.str = private unnamed_addr constant [8 x i8] c"x = %d\0A\00", align 1<br class="">
@.str2 = private unnamed_addr constant [8 x i8] c"p = %d\0A\00", align 1<br class="">
<br class="">
; declare printf, we'll use this later for printf style debugging.<br class="">
declare i32 @printf(i8*, ...)<br class="">
<br class="">
; define a main function.<br class="">
define i32 @main() prefix i32 123 {<br class="">
; obtain a i32 pointer to the main function.<br class="">
; the prefix data is right before that pointer.<br class="">
%main = bitcast i32 ()* @main to i32*<br class="">
<br class="">
; use the gep, to cmpute the start of the prefix data.<br class="">
%prefix_ptr = getelementptr inbounds i32, i32* %main, i32 -1<br class="">
; and load it.<br class="">
%prefix_val = load i32, i32* %prefix_ptr<br class="">
<br class="">
; print that value.<br class="">
%ret = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str2, i32 0, i32 0), i32 %prefix_val)<br class="">
<br class="">
; similarly let's do the same with the global x.<br class="">
%1 = alloca i32, align 4<br class="">
store i32 0, i32* %1, align 4<br class="">
%2 = load i32, i32* @x, align 4<br class="">
%3 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str, i32 0, i32 0), i32 %2)<br class="">
ret i32 0<br class="">
}<br class="">
<br class="">
gives the following result (expected)<br class="">
<br class="">
$ clang test.ll<br class="">
$ ./a.out<br class="">
p = 123<br class="">
x = 10<br class="">
<br class="">
however, with -dead_strip on macOS, we see the following:<br class="">
<br class="">
$ clang test.ll -dead_strip<br class="">
$ ./a.out<br class="">
p = 0<br class="">
x = 10<br class="">
<br class="">
Thus I believe we are incorrectly stripping prefix data when linking with -dead_strip on macOS.<br class="">
<br class="">
As I do not have a bugzilla account, and hence cannot post this as a proper bug report.<br class="">
<br class="">
Cheers,<br class="">
Moritz<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div><br class=""></div>
</div></div><br class="">______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div></div></div><span class="m_37750768197969627HOEnZb"><font color="#888888" class="">-- <br class=""><div class="m_37750768197969627m_-2098018759435103914gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class="">-- <div class="">Peter</div></div></div>
</font></span></div>
</blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>