This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Get rid of ASM_SIZE_DIRECTIVE (take 2)


(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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]