<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 24, 2014 at 4:44 PM, 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"><div class="">On 22 March 2014 15:26, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org">compnerd@compnerd.org</a>> wrote:<br>

> Author: compnerd<br>
> Date: Sat Mar 22 14:26:18 2014<br>
> New Revision: 204544<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=204544&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=204544&view=rev</a><br>
> Log:<br>
> ARM IAS: properly handle function entries in .thumb<br>
><br>
> When a label is parsed, check if there is type information available for the<br>
> label.  If so, check if the symbol is a function.  If the symbol is a function<br>
> and we are in thumb mode and no explicit thumb_func has been emitted, adjust the<br>
> symbol data to indicate that the function definition is a thumb function.<br>
><br>
> The application of this inferencing is improved value handling in the object<br>
> file (the required thumb bit is set on symbols which are thumb functions).  It<br>
> also helps improve compatibility with binutils.<br>
><br>
> The one complication that arises from this handling is the MCAsmStreamer.  The<br>
> default implementation of getOrCreateSymbolData in MCStreamer does not support<br>
> tracking the symbol data.  In order to support the semantics of thumb functions,<br>
> track symbol data in assembly streamer.  Although O(n) in number of labels in<br>
> the TU, this is already done in various other streamers and as such the memory<br>
> overhead is not a practical concern in this scenario.<br>
<br>
</div>This is quiet odd.<br>
<br>
If we really need a MCSymbolData in the asm streamer, we should move<br>
the MCAssembler implementation of getOrCreateSectionData to MCStreamer<br>
and make it non virtual.<br></blockquote><div><br></div><div>Sure, that sounds reasonable.  I can try to take a stab on that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

But why is the parser the one that needs to keep track if we are on<br>
thumb mode or not? Can't you do the tracking in the streamer and just<br>
mark the symbol in EmitLabel? The current implementation might<br>
actually have a bug when handling global inline asm. We create a new<br>
asm parser for it, so it will fail to mark a symbol defined in global<br>
asm as thumb when compiling with -mthumb, no?<br></blockquote><div><br></div><div>This isnt changing that behaviour, it is simply augmenting it so that more functions are marked as a thumb function implicitly rather than via an explicit .thumb_func marker.  Moving the tracking into the streamer is a TODO I believe, and something that would be nice to fix.  I think I would like to deal with the separate thumb_funcs table that we maintain first and then take a look at this cleanup.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Rafael</blockquote></div><div><br></div>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org
</div></div>