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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Mon Mar 24 16:44:31 PDT 2014

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.

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?


More information about the llvm-commits mailing list