<div dir="ltr"><div><div>Hi Saleem,<br><br></div>Any updated comments on this?  Thanks.<br><br></div>Logan<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 5:46 AM, Logan Chien <span dir="ltr"><<a href="mailto:tzuhsiang.chien@gmail.com" target="_blank">tzuhsiang.chien@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi Saleem,<br><br></div>Sorry for the late reply.<br><br></div>Although I am not strongly oppose to the idea to provide both inline and extern version, I am concerned that exporting these symbols will further fragmentize the ecosystem.  With these symbol exported, some application will start to simply declaring their own prototype and referencing the these functions directly instead of including <unwind.h>.  IMO, it should be conservative to extend an ABI especially when the extension is neither documented nor de facto in the ARM ecosystem.<span class=""><br><br>> On the other hand, when applications are using the interfaces, expecting
 the unwind APIs, I think that they should continue to function.  
Providing both the external as well as the inlined version should 
achieve that.<br><br></span></div>In fact, this is what I wish to avoid.  IMO, for the application developers, they should simply include <unwind.h> if they need these functions, instead of declaring their own function prototype.<br><br></div>Sincerely,<br></div>Logan<br></div></blockquote></div><br></div></div>