<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 9, 2016 at 5:33 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr"><br>
On Apr 8, 2016 10:43 PM, "Peter Collingbourne" <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:<br>
><br>
> pcc added a comment.<br>
><br>
> It seems feasible, I'll see if I can do it. In the meantime, this fixes the issue with backtrace(), and also matches gold's behavior, so maybe we can land this as a first step with a FIXME.</p>
</span><p dir="ltr">Please don't. Just subtracting one each time from fde_count should be easy.</p>
<p dir="ltr">Matching gold's behavior sounds like just cargo cult in this case.</p></blockquote><div>Okay, fair enough. I've uploaded a new patch that just sets fde_count to the number of FDEs actually emitted.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<p dir="ltr">> I was also thinking about cases where the unwind info for functions with identical bodies was semantically different. For example, I suppose you might be able to have functions with identical bodies but different personality functions. If that's possible, I suppose we may need to inhibit ICF in such cases and do something completely different here.<br>
></p>
</span><p dir="ltr">If you avoid ICF you would not need to do anything in here, no?</p></blockquote><div>Maybe. I was thinking that whatever data structure we build in ICF for the FDEs could be shared between ICF and the .eh_frame{,hdr} writer code. But anyway, that probably doesn't matter for now.</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>