* Re: glibc broken with 3.4... [not found] ` <u87k4kempg.fsf@gromit.moeb> @ 2003-09-07 14:43 ` Jan Hubicka 2003-09-07 19:21 ` Richard Henderson 0 siblings, 1 reply; 5+ messages in thread From: Jan Hubicka @ 2003-09-07 14:43 UTC (permalink / raw) To: Andreas Jaeger, gcc, zack, geoffk; +Cc: 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: glibc broken with 3.4... 2003-09-07 14:43 ` glibc broken with 3.4 Jan Hubicka @ 2003-09-07 19:21 ` Richard Henderson 2003-09-07 21:32 ` Jan Hubicka 0 siblings, 1 reply; 5+ messages in thread From: Richard Henderson @ 2003-09-07 19:21 UTC (permalink / raw) To: Jan Hubicka; +Cc: Andreas Jaeger, gcc, zack, geoffk 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~ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: glibc broken with 3.4... 2003-09-07 19:21 ` Richard Henderson @ 2003-09-07 21:32 ` Jan Hubicka 2003-09-07 21:59 ` Richard Henderson 0 siblings, 1 reply; 5+ messages in thread From: Jan Hubicka @ 2003-09-07 21:32 UTC (permalink / raw) To: Richard Henderson, Jan Hubicka, Andreas Jaeger, gcc, zack, geoffk > 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~ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: glibc broken with 3.4... 2003-09-07 21:32 ` Jan Hubicka @ 2003-09-07 21:59 ` Richard Henderson 2003-09-07 23:26 ` Jan Hubicka 0 siblings, 1 reply; 5+ messages in thread From: Richard Henderson @ 2003-09-07 21:59 UTC (permalink / raw) To: Jan Hubicka; +Cc: Jan Hubicka, Andreas Jaeger, gcc, zack, geoffk 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~ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: glibc broken with 3.4... 2003-09-07 21:59 ` Richard Henderson @ 2003-09-07 23:26 ` Jan Hubicka 0 siblings, 0 replies; 5+ messages in thread From: Jan Hubicka @ 2003-09-07 23:26 UTC (permalink / raw) To: Richard Henderson, Jan Hubicka, Jan Hubicka, Andreas Jaeger, gcc, zack, geoffk > 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~ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-09-07 21:59 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <u8u17qjsy9.fsf@gromit.moeb> [not found] ` <20030906185819.GA1599@kam.mff.cuni.cz> [not found] ` <u84qzpgm7z.fsf@gromit.moeb> [not found] ` <20030907110551.GL1599@kam.mff.cuni.cz> [not found] ` <u8fzj8eq8o.fsf@gromit.moeb> [not found] ` <20030907124924.GB14387@kam.mff.cuni.cz> [not found] ` <u87k4kempg.fsf@gromit.moeb> 2003-09-07 14:43 ` glibc broken with 3.4 Jan Hubicka 2003-09-07 19:21 ` Richard Henderson 2003-09-07 21:32 ` Jan Hubicka 2003-09-07 21:59 ` Richard Henderson 2003-09-07 23:26 ` Jan Hubicka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).