[llvm] r204544 - ARM IAS: properly handle function entries in .thumb

[Saleem Abdulrasool]

On Mon, Mar 24, 2014 at 4:44 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 22 March 2014 15:26, Saleem Abdulrasool <compnerd at compnerd.org> wrote:
> > Author: compnerd
> > Date: Sat Mar 22 14:26:18 2014
> > New Revision: 204544
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=204544&view=rev
> > Log:
> > ARM IAS: properly handle function entries in .thumb
> >
> > When a label is parsed, check if there is type information available for
> the
> > label.  If so, check if the symbol is a function.  If the symbol is a
> function
> > and we are in thumb mode and no explicit thumb_func has been emitted,
> adjust the
> > symbol data to indicate that the function definition is a thumb function.
> >
> > The application of this inferencing is improved value handling in the
> object
> > file (the required thumb bit is set on symbols which are thumb
> functions).  It
> > also helps improve compatibility with binutils.
> >
> > The one complication that arises from this handling is the
> MCAsmStreamer.  The
> > default implementation of getOrCreateSymbolData in MCStreamer does not
> support
> > tracking the symbol data.  In order to support the semantics of thumb
> functions,
> > track symbol data in assembly streamer.  Although O(n) in number of
> labels in
> > the TU, this is already done in various other streamers and as such the
> memory
> > overhead is not a practical concern in this scenario.
>
> This is quiet odd.
>
> If we really need a MCSymbolData in the asm streamer, we should move
> the MCAssembler implementation of getOrCreateSectionData to MCStreamer
> and make it non virtual.
>

Sure, that sounds reasonable.  I can try to take a stab on that.


> But why is the parser the one that needs to keep track if we are on
> thumb mode or not? Can't you do the tracking in the streamer and just
> mark the symbol in EmitLabel? The current implementation might
> actually have a bug when handling global inline asm. We create a new
> asm parser for it, so it will fail to mark a symbol defined in global
> asm as thumb when compiling with -mthumb, no?
>

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.


> Cheers,
> Rafael


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140324/ad9dee9b/attachment.html>