Re: glibc broken with 3.4...

Re: glibc broken with 3.4...

[Jan Hubicka]

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

Re: glibc broken with 3.4...

[Richard Henderson]

On Sun, Sep 07, 2003 at 03:58:29PM +0200, Jan Hubicka wrote:
> extern int t();
> q()
> {t();}
> extern int t() asm("t2");

I don't think we should support this.  The glibc case I fear does 
need to be handled.  Both with an asm specifier as above or with

  #pragma redefined_extname oldname newname
  #pragma extern_prefix "prefix"

which we implemented for solaris and tru64 system header support.


r~

Re: glibc broken with 3.4...

[Jan Hubicka]

> On Sun, Sep 07, 2003 at 03:58:29PM +0200, Jan Hubicka wrote:
> > extern int t();
> > q()
> > {t();}
> > extern int t() asm("t2");
> 
> I don't think we should support this.  The glibc case I fear does 
> need to be handled.  Both with an asm specifier as above or with
> 
>   #pragma redefined_extname oldname newname
>   #pragma extern_prefix "prefix"
> 
> which we implemented for solaris and tru64 system header support.

I made patch for this:
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg01832.html
it, however refuse more sanier testcase

extern int __isinf (double __value) __attribute__ ((__const__));
extern __typeof (__isinf) __isinf __asm__ ("" "__GI___isinf") __attribute__ ((visibility ("hidden")));
extern __typeof (__isinf) __GI___isinf; 

This is what is done in glibc.  This would be acceptable, but __typeof
(__isinf) counts as used so error fires.  In the case we want to accept
this somewhat, we would run into issues with slightly modified testcase
where extern inline version of function is provided first and rename
later.  This would break already without my code for renaming in cgraph
hashtables I use on hammer branch as the extern inline body is finalized
first.

Any idea where to go from here?

Honza
> 
> 
> r~

Re: glibc broken with 3.4...

[Richard Henderson]

On Sun, Sep 07, 2003 at 10:38:21PM +0200, Jan Hubicka wrote:
> This is what is done in glibc.  This would be acceptable, but __typeof
> (__isinf) counts as used so error fires.

Ug.  I've no idea what to do about this, except to somehow note that
sizeof, typeof, alignof doesn't actually use the assembler level symbol
at all.  That's pretty sketchy though, cause I'm sure that folks will
say the same thinga bout __builtin_constant_p or anything else that
doesn't really depend on some bits of metadata associated with a symbol.

For C++ I'm sure that it still needs to be a "use" of some sort, since
it'll require templates to be instantiated, etc.


r~

Re: glibc broken with 3.4...

[Jan Hubicka]

> On Sun, Sep 07, 2003 at 10:38:21PM +0200, Jan Hubicka wrote:
> > This is what is done in glibc.  This would be acceptable, but __typeof
> > (__isinf) counts as used so error fires.
> 
> Ug.  I've no idea what to do about this, except to somehow note that
> sizeof, typeof, alignof doesn't actually use the assembler level symbol
> at all.  That's pretty sketchy though, cause I'm sure that folks will
> say the same thinga bout __builtin_constant_p or anything else that
> doesn't really depend on some bits of metadata associated with a symbol.

One can do test whether cgraph node has been already created.  That
notion of use is extremly lazy and will avoid the problem with updating
hashtables, however it is very implementation specific and will likely
change in future so I am not sure it is good choice.

It also still haves problem with difining body of extern inline function
being an "use" (or use in different extern inline function) and that is
precisely what glibc does.

Perhaps we can go with updating the hashtables and allowing the renaming
after all, but that is nasty as well... (tought I think I got it working
right on hammer branch)

Honza
> 
> For C++ I'm sure that it still needs to be a "use" of some sort, since
> it'll require templates to be instantiated, etc.
> 
> 
> r~