[PATCH] Get rid of ASM_SIZE_DIRECTIVE (take 2)

Chris Metcalf cmetcalf@tilera.com
Wed Sep 19 18:38:00 GMT 2012


(Resending to avoid some html foisted on me by Thunderbird.)

On 9/19/2012 2:18 PM, Mike Frysinger wrote:
> On Tuesday 18 September 2012 14:57:17 Carlos O'Donell wrote:
>> On 9/18/2012 1:06 PM, Roland McGrath wrote:
>>> That looks fine to me, though I am having second thoughts about the exact
>>> choice of name. SYMBOL_SIZE doesn't really communicate that it computes
>>> based on ., i.e. that the placement of the macro relative to assembly
>>> code following the symbol is crucial. Good names are not coming to mind
>>> just now.
>>
>> Imply that it's computed: SYMBOL_CALC_SIZE?
>>
>> Imply that it's positional: SYMBOL_HERE_SIZE?
>
> if we aren't terribly set on names, i'd say let's just use the same macros
> that the kernel already does since other projects have picked up those
styles.

I think this would suggest just making the default END macro set the
function size, using an explicit ".size", which brings us full-circle to
the idea of just getting rid of ASM_SIZE_DIRECTIVE. :-)  However, the glibc
use of END implies a function symbol, since most architectures include
cfi_endproc in it, unlike the kernel use.  You could imagine using
END_SYM(name), for example, to mean purely the .size directive, then the
function-centric macro END(name) could just include END_SYM(name) as part
of its expansion.  The upshot is we could just bomb ASM_SIZE_DIRECTIVE to
END_SYM everywhere, and move the definition out of the sysdep hierarchy.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com



More information about the Libc-alpha mailing list