Re: [PATCH] In _IEEE_LIBM mode, use weak symbols instead of wrapper funcs [v3]

[Craig Howland <howland at LGSInnovations dot com>]

On 09/21/2018 04:58 PM, Keith Packard wrote:
> Craig Howland <howland@LGSInnovations.com> writes:
>
> > It's no difference than a weak alias--it requires object file support.  To quote
> > from the GCC manual about a function alias attribute (which is what the macro
> > ends up using), "This attribute requires assembler and object file support, and
> > may not be available on all targets."
> It is different from weak in that it doesn't require any object file or
> linker support. For instance, here's what the __strong_reference does in
> e_acos.c:
>
> 	.globl	acos
> 	.set	acos,__ieee754_acos
>
> Using __weak_reference does this instead:
>
> 	.weak acos
> 	.equ acos, __ieee754_acos
>
> The GCC docs don't really talk about non-weak aliases at all which makes
> me unhappy as it would be useful to know if the statement you quoted
> refers to *all* aliases, or only weak aliases.
The quoted statement comes from the alias definition, which is strong unless 
weak is added to it, so I take it as applying to all. (The example in the manual 
has weak in it, but that doesn't mean the whole description only applies with 
weak.  Weak has its own, separate, description which is even more limited (only 
ELF and a.out), which implies the one for alias applies to all.)  However, I 
don't know for sure for all assemblers and object file formats. Someone on the 
list probably does.
> However, given the current GCC docs, we'll certainly want to use a
> separate conditional instead of attempting to auto-detect this mode.
>
> I'll add that, but I won't add any autotools mechanism to define it as I
> cannot rebuild the configure scripts on Debian any longer.
>
> I'm not getting a sense of whether you think this is a useful change
> though; it seems like a fairly obvious optimization of the existing
> feature to me, but perhaps you're finding it too complicated to be
> useful upstream?
The goal is a good one (getting rid of the additional function call when it 
degenerates to just a wrapper), but it does need a method that won't break any 
targets.