[llvm] r204544 - ARM IAS: properly handle function entries in .thumb
rafael.espindola at gmail.com
Mon Mar 24 21:56:27 PDT 2014
On 25 March 2014 00:18, Saleem Abdulrasool <compnerd at compnerd.org> wrote:
> 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.
OK. But if this is possible, I think it is preferable to the above
option. That is, please don't move getSymbolData to MCStreamer if you
plan to track "thumbness" in the object streamers themselves instead
of in the asm printer.
More information about the llvm-commits