<div dir="ltr"><span style="font-size:12.8px">Hi All,</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">It's good to hear other people are interested.</div><span class="gmail-im" style="font-size:12.8px"><div><br></div><div>> <span style="font-size:12.8px">Have you considered using optimization remarks for this rather than rolling your own infrastructure.</span><span style="font-size:12.8px"> </span></div><div><br></div></span><div style="font-size:12.8px">This could work for our local testing with significant infrastructure changes, but we have some other use cases where using the remarks wouldn't work or wouldn't be convenient.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><span style="font-size:12.8px">- Getting stack sizes from binaries that we didn't build</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">- Providing stack size data to users when they inspect their own binaries</span></div><span class="gmail-im" style="font-size:12.8px"><div><br></div><div><span style="font-size:12.8px">> Can you let us know what the change above does that reading the stack</span><br style="font-size:12.8px"><span style="font-size:12.8px">> size from the .debug_frame or .eh_frame doesn't?</span></div><div><span style="font-size:12.8px"><br></span></div></span><div style="font-size:12.8px"><span style="font-size:12.8px">We won't have the .debug_frame on release builds</span><span style="font-size:12.8px">. T</span><span style="font-size:12.8px">he </span><span style="font-size:12.8px">.eh_frame does not always have enough information to calculate the stack sizes (I understand that this might not be the case for ARM).</span></div><div class="gmail_extra" style="font-size:12.8px"><br></div><div class="gmail_extra" style="font-size:12.8px">Thanks,</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(0,0,0);font-family:'Segoe UI','Segoe UI Web Regular','Segoe UI Symbol','Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:18.85px">Sean Eveson</span><br style="color:rgb(0,0,0);font-family:'Segoe UI','Segoe UI Web Regular','Segoe UI Symbol','Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:18.85px"><span style="color:rgb(0,0,0);font-family:'Segoe UI','Segoe UI Web Regular','Segoe UI Symbol','Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13px;line-height:18.85px">SN Systems - Sony Interactive Entertainment</span><br></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Sep 1, 2017 at 9:48 AM, Peter Smith <span dir="ltr"><<a href="mailto:peter.smith@linaro.org" target="_blank">peter.smith@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Sean,<br>
<br>
This is potentially interesting to Arm and other targets that end up<br>
in embedded systems. Of particular use for this information is<br>
estimating the maximum stack usage for the program.<br>
<br>
In Arm's proprietary toolchain we use the .debug_frame information to<br>
calculate the per-function stack-size. This is a bit more work than<br>
just reading off the value from a table but it doesn't require any<br>
custom compiler work or special ELF sections, and does work with<br>
assembler assuming that the author has put in the necessary<br>
directives. It has the downside of always requiring .debug_frame (or<br>
.eh_frame) sections for release builds.<br>
<br>
Can you let us know what the change above does that reading the stack<br>
size from the .debug_frame or .eh_frame doesn't?<br>
<br>
Peter<br>
<br>
On 31 August 2017 at 15:09, Sean Eveson via llvm-dev<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Hi All,<br>
><br>
><br>
><br>
> We have a local change in the X86AsmPrinter that outputs a section<br>
> containing metadata on function stack sizes. We use this to measure changes<br>
> to stack size between versions of the compiler and it also allows our<br>
> licensees to do the same for their code.<br>
><br>
><br>
><br>
> The section simply contains pairs of function symbol references (8 byte) and<br>
> stack sizes (unsigned LEB128).<br>
><br>
><br>
><br>
> We would like to upstream this change as a PS4 only modification, or as a<br>
> more general cross platform one.<br>
><br>
><br>
><br>
> Would people be interested in (or happy with) such a patch, target specific<br>
> or otherwise?<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
><br>
> Sean Eveson<br>
> SN Systems - Sony Interactive Entertainment<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<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>
</div></div></blockquote></div><br></div></div>