Re: glibc broken with 3.4...

[Jan Hubicka <hubicka at ucw dot cz>]

Geoff, Zack and others :)
the idea of diallowing asm renamers after very first declaration would
break at least glibc in serious way, so we probably need to re-consider
this.
> 
> It's not that easy...
> 
> We have in include/math.h:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> #ifndef	_MATH_H
> 
> #include <math/math.h>
> 
> /* Now define the internal interfaces.  */
> extern int __matherr (struct exception *__exc);
> 
> # if !defined NOT_IN_libc || defined IS_IN_libm
> hidden_proto (__finite)
> hidden_proto (__isinf)
> hidden_proto (__isnan)
> ....
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> And in include/libc-symbols.h have:
> 
> #  define hidden_proto(name, attrs...) \
>   __hidden_proto (name, __GI_##name, ##attrs)
> #  define __hidden_proto(name, internal, attrs...) \
>   extern __typeof (name) internal; \
>   extern __typeof (name) name __asm__ (__hidden_asmname (#internal)) \
>   __hidden_proto_hiddenattr (attrs);
> #   define __hidden_proto_hiddenattr(attrs...) \
>   __attribute__ ((visibility ("hidden"), ##attrs))
> 
> 
> math/math.h includes math/bits/mathcalls.h with:
> __MATHDECL_1 (int,__isnan,, (_Mdouble_ __value)) __attribute__ ((__const__));
> 
> This expands to:
> extern int __isnan (double __value) __attribute__ ((__const__));
> ...
> extern __typeof (__isnan) __GI___isnan; extern __typeof (__isnan) __isnan __asm__ ("" "__GI___isnan") __attribute__ ((visibility ("hidden")));
> 
> We cannot change the order here since we need the __typeof (__isnan).
> 
> I don't see a direct solution for this without duplicating headers
> - and duplicating headers is something I really do not like to do
> since it cases even more trouble :-(
> 
> Do you have any idea?

Lets ask in public :)
I think we can massage things further and basically make GCC to believe
that after the asm renamer it is seeing completely new function.  This
is not problem for callgraph code as it is relying on assembler name to
identify things, but it may be issue for the frontend as identifier
hashtable needs to be updated.

In that way folllowing code:

extern int t();
q()
{t();}
extern int t() asm("t2");
q2()
{
t();
}

would have well defined meaning of q calling t and q2 calling t.
On the other hand

inline int t()
{
....
}
q()
{t();}
int t() asm("t2");
q2()
{
t();
}

won't get you t inlined in q2 that is perhaps what glibc expects.

Honza
> 
> Andreas
> -- 
>  Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
>   SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
>    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126