<div dir="ltr">Hi Andrew,<div><br></div><div style>I just ran the check-all tests on this patch on x86_64 and it found 5 failures (attached). Are you sure you run the tests recently? Would be good to have both ARM and x86_64 check-all covered, at least. The test-suite buildbot will catch errors in the execution, if there's any, so watch out for emails from them.</div>
<div style><br></div><div style>cheers,</div><div style>--renato</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 May 2013 11:55, Andrew Turner <span dir="ltr"><<a href="mailto:andrew@fubar.geek.nz" target="_blank">andrew@fubar.geek.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 22 Apr 2013 11:22:59 +0100<br>
Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br>
<br>
> Hi Andrew,<br>
><br>
> Sorry for the delay. I had a read on the code around it and it seems<br>
> that with your patch, the stack will always grow if there is a call<br>
> and not a frame pointer. I'm not sure how this correlates with<br>
> functions without stack setup, line __aeabi_read_tp, but it might<br>
> bloat the stack for many other unrelated functions.<br>
><br>
> However, I can see from the comments that adjusting the stack should<br>
> be done on any function call, and I don't know that part of the code<br>
> well enough, so if no one else has any objections, I'm ok with your<br>
> patch.<br>
<br>
</div>Is someone able to commit this patch?<br>
<span class="HOEnZb"><font color="#888888"><br>
Andrew<br>
</font></span></blockquote></div><br></div>