Aliases ...

Aliases ...

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]


From: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19346
 

Description:  [reply] 
Last confirmed: 2005-01-09 15:50 
Opened: 2005-01-09 10:11 

With current GCC CVS I get lots of warnings when compiling glibc 
about aliases to undefined symbols: 
 
aj@gromit:~/tmp> /opt/gcc/4.0-devel/bin/gcc -O2 -c test.i 
test.i:2: warning: ?__libc_errno? aliased to undefined symbol ?errno? 
aj@gromit:~/tmp> nm test.o 
0000000000000004 C errno 
 
One testcase is: 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
int errno; 
extern  int __libc_errno __attribute__ ((alias ("errno"))); 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

 ------- Additional Comment #1 From Andrew Pinski 2005-01-09 15:50 [reply] ------- 
Confirmed.
 

 ------- Additional Comment #2 From Richard Henderson 2005-01-09 18:46 [reply] ------- 
I hadn't realized aliases to COMMON symbols ever worked...
 

 ------- Additional Comment #3 From Richard Henderson 2005-01-09 18:49 [reply] ------- 
Indeed, they DO NOT work, and never have.  The warning is correct.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So, what shall we do with glibc?

Btw. I get this warning also for:
wcsftime_l.c:26: warning: ‘wcsftime_l’ aliased to undefined symbol ‘__wcsftime_l’
../nss/getXXent_r.c:203: warning: ‘getgrent_r’ aliased to undefined symbol ‘__new_getgrent_r’
../sysdeps/posix/pathconf.c:237: warning: ‘pathconf’ aliased to undefined symbol‘__pathconf’
../sysdeps/posix/fpathconf.c:241: warning: ‘fpathconf’ aliased to undefined symbol ‘__fpathconf’

Richard, do these also point to a problem in glibc?

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Aliases ...

[H. J. Lu]

On Sun, Jan 09, 2005 at 10:00:25PM +0100, Andreas Jaeger wrote:
> 
> From: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19346
>  
> 
> Description:  [reply] 
> Last confirmed: 2005-01-09 15:50 
> Opened: 2005-01-09 10:11 
> 
> With current GCC CVS I get lots of warnings when compiling glibc 
> about aliases to undefined symbols: 
>  
> aj@gromit:~/tmp> /opt/gcc/4.0-devel/bin/gcc -O2 -c test.i 
> test.i:2: warning: ?__libc_errno? aliased to undefined symbol ?errno? 
> aj@gromit:~/tmp> nm test.o 
> 0000000000000004 C errno 
>  

See

http://sources.redhat.com/ml/libc-alpha/2004-01/msg00232.html

Should I apply

http://sources.redhat.com/ml/binutils/2004-02/msg00066.html

I got

[hjl@gnu-10 tmp]$ /usr/gcc-4.0/bin/gcc -O2 x.c
x.c:2: warning: \uffff\uffff\uffff__libc_errno\uffff\uffff\uffff
aliased to undefined symbol \uffff\uffff\ufffferrno\uffff\uffff\uffff
/tmp/cczKnuV0.s: Assembler messages:
/tmp/cczKnuV0.s:6: Error: `__libc_errno' can't be equated to common
symbol


H.J.

Re: Aliases ...

[H. J. Lu]

On Mon, Jan 10, 2005 at 09:14:07AM -0800, H. J. Lu wrote:
> On Sun, Jan 09, 2005 at 10:00:25PM +0100, Andreas Jaeger wrote:
> > 
> > From: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19346
> >  
> > 
> > Description:  [reply] 
> > Last confirmed: 2005-01-09 15:50 
> > Opened: 2005-01-09 10:11 
> > 
> > With current GCC CVS I get lots of warnings when compiling glibc 
> > about aliases to undefined symbols: 
> >  
> > aj@gromit:~/tmp> /opt/gcc/4.0-devel/bin/gcc -O2 -c test.i 
> > test.i:2: warning: ?__libc_errno? aliased to undefined symbol ?errno? 
> > aj@gromit:~/tmp> nm test.o 
> > 0000000000000004 C errno 
> >  
> 
> See
> 
> http://sources.redhat.com/ml/libc-alpha/2004-01/msg00232.html
> 
> Should I apply
> 
> http://sources.redhat.com/ml/binutils/2004-02/msg00066.html
> 
> I got
> 
> [hjl@gnu-10 tmp]$ /usr/gcc-4.0/bin/gcc -O2 x.c
> x.c:2: warning: \uffff\uffff\uffff__libc_errno\uffff\uffff\uffff
> aliased to undefined symbol \uffff\uffff\ufffferrno\uffff\uffff\uffff
> /tmp/cczKnuV0.s: Assembler messages:
> /tmp/cczKnuV0.s:6: Error: `__libc_errno' can't be equated to common
> symbol

I checked in my gas patch. The new assembler won't allow it anymore.


H.J.

Re: Aliases ...

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]

Richard Henderson <rth@redhat.com> writes:

> On Sun, Jan 09, 2005 at 10:00:25PM +0100, Andreas Jaeger wrote:
>> One testcase is: 
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>> int errno; 
>> extern  int __libc_errno __attribute__ ((alias ("errno"))); 
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ...
>> So, what shall we do with glibc?
>
> For this case, either initialize the variable, or use -fno-common.
>
>> Btw. I get this warning also for:
>> wcsftime_l.c:26: warning: ‘wcsftime_l’ aliased to undefined symbol ‘__wcsftime_l’
>> ../nss/getXXent_r.c:203: warning: ‘getgrent_r’ aliased to undefined symbol ‘__new_getgrent_r’
>> ../sysdeps/posix/pathconf.c:237: warning: ‘pathconf’ aliased to undefined symbol‘__pathconf’
>> ../sysdeps/posix/fpathconf.c:241: warning: ‘fpathconf’ aliased to undefined symbol ‘__fpathconf’
>> 
>
> But these are functions, not variables, so this must be a different
> problem.  You can re-open the same bug with these different test cases,
> or create a new one, as you choose.

I guess this warning is valid, I get:
t.c:17: warning: ‘passwd2des’ aliased to undefined symbol ‘passwd2des_internal’

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void passwd2des_internal (char *pw, char *key);

extern __typeof (passwd2des_internal) __GI_passwd2des_internal;
extern __typeof (passwd2des_internal) passwd2des_internal __asm__ ("" "__GI_passwd2des_internal") __attribute__ ((visibility ("hidden")));

void
passwd2des_internal (char *pw, char *key)
{
  int i;

  for (i = 0; *pw && i < 8; ++i)
    key[i] ^= *pw++ << 1;

}

__asm__ (".globl passwd2des_internal ; .set passwd2des_internal, __GI_passwd2des_internal");
extern __typeof (passwd2des_internal) passwd2des __attribute__ ((alias ("passwd2des_internal")));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Changing the last line to:
extern __typeof (passwd2des_internal) passwd2des __attribute__ ((alias ("__GI_passwd2des_internal")));

removes the warning, so I guess we need to fix this in glibc :-(

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Aliases ...

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]


Let's look closer at one example:
../sysdeps/ieee754/dbl-64/s_isinf.c:29: warning: ‘isinf’ aliased to undefined symbol ‘__isinf’

The function is:

int
__isinf (double x)
{
	int32_t hx,lx;
	EXTRACT_WORDS(hx,lx,x);
	lx |= (hx & 0x7fffffff) ^ 0x7ff00000;
	lx |= -lx;
	return ~(lx >> 31) & (hx >> 30);
}
hidden_def (__isinf)
weak_alias (__isinf, isinf)

And the warning appears for the weak_alias.  If I change it to:
weak_alias (__GI___isinf, isinf)

Everything is fine.

so, is this the right way to do - and should we add a new macro, e.g.
hidden_weak_alias to use in place of weak_alias above?

Or how should this be solved to make GCC happy - and be convenienent
for glibc?

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Aliases ...

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]


I still see these warnings and would like to help getting them fixed.

Richard, what do you suggest is the best thing to do?

Andreas

Andreas Jaeger <aj@suse.de> writes:

> Let's look closer at one example:
> ../sysdeps/ieee754/dbl-64/s_isinf.c:29: warning: ‘isinf’ aliased to undefined symbol ‘__isinf’
>
> The function is:
>
> int
> __isinf (double x)
> {
> 	int32_t hx,lx;
> 	EXTRACT_WORDS(hx,lx,x);
> 	lx |= (hx & 0x7fffffff) ^ 0x7ff00000;
> 	lx |= -lx;
> 	return ~(lx >> 31) & (hx >> 30);
> }
> hidden_def (__isinf)
> weak_alias (__isinf, isinf)
>
> And the warning appears for the weak_alias.  If I change it to:
> weak_alias (__GI___isinf, isinf)
>
> Everything is fine.
>
> so, is this the right way to do - and should we add a new macro, e.g.
> hidden_weak_alias to use in place of weak_alias above?
>
> Or how should this be solved to make GCC happy - and be convenienent
> for glibc?
>
> Andreas

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Aliases ...

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

Richard Henderson <rth@redhat.com> writes:

> On Sun, Jan 09, 2005 at 10:00:25PM +0100, Andreas Jaeger wrote:
>> One testcase is: 
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>> int errno; 
>> extern  int __libc_errno __attribute__ ((alias ("errno"))); 
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ...
>> So, what shall we do with glibc?
>
> For this case, either initialize the variable, or use -fno-common.

Here's a patch to initialize it - it removes the warning.

Ok to commit?

Andreas

2005-01-14  Andreas Jaeger  <aj@suse.de>

	* sysdeps/generic/errno.c: Initialize errno.

============================================================
Index: sysdeps/generic/errno.c
--- sysdeps/generic/errno.c	4 Oct 2004 20:59:41 -0000	1.7
+++ sysdeps/generic/errno.c	14 Jan 2005 08:52:47 -0000
@@ -1,5 +1,5 @@
 /* Definition of `errno' variable.  Canonical version.
-   Copyright (C) 2002, 2004 Free Software Foundation, Inc.
+   Copyright (C) 2002, 2004, 2005 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
 
    The GNU C Library is free software; you can redistribute it and/or
@@ -29,7 +29,9 @@ int rtld_errno attribute_hidden;
 
 #elif USE___THREAD
 
-__thread int errno;
+/* We have to initialize errno, since aliasing of a common symbol does
+   not work.  */
+__thread int errno = 0;
 extern __thread int __libc_errno __attribute__ ((alias ("errno")))
   attribute_hidden;
 

-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Aliases ...

[Roland McGrath]

> Here's a patch to initialize it - it removes the warning.

This really happens with __thread?  The right thing when this issue comes
up is to use __attribute__((nocommon)).

> Ok to commit?
> 
> Andreas
> 
> 2005-01-14  Andreas Jaeger  <aj@suse.de>
> 
> 	* sysdeps/generic/errno.c: Initialize errno.
> 
> ============================================================
> Index: sysdeps/generic/errno.c
> --- sysdeps/generic/errno.c	4 Oct 2004 20:59:41 -0000	1.7
> +++ sysdeps/generic/errno.c	14 Jan 2005 08:52:47 -0000
> @@ -1,5 +1,5 @@
>  /* Definition of `errno' variable.  Canonical version.
> -   Copyright (C) 2002, 2004 Free Software Foundation, Inc.
> +   Copyright (C) 2002, 2004, 2005 Free Software Foundation, Inc.
>     This file is part of the GNU C Library.
>  
>     The GNU C Library is free software; you can redistribute it and/or
> @@ -29,7 +29,9 @@ int rtld_errno attribute_hidden;
>  
>  #elif USE___THREAD
>  
> -__thread int errno;
> +/* We have to initialize errno, since aliasing of a common symbol does
> +   not work.  */
> +__thread int errno = 0;
>  extern __thread int __libc_errno __attribute__ ((alias ("errno")))
>    attribute_hidden;
>  
> 
> -- 
>  Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
>   SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Re: Aliases ...

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

Roland McGrath <roland@redhat.com> writes:

>> Here's a patch to initialize it - it removes the warning.
>
> This really happens with __thread?  The right thing when this issue comes
> up is to use __attribute__((nocommon)).


This test case does indeed warn:

 __thread int errno __attribute__ ((nocommon));
extern __thread int __libc_errno __attribute__ ((alias ("errno")));

with:
test.i:2: warning: ‘__libc_errno’ aliased to undefined symbol ‘errno’

Initialising it to 0 fixes it,

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Aliases ...

[Roland McGrath]

> Roland McGrath <roland@redhat.com> writes:
> 
> >> Here's a patch to initialize it - it removes the warning.
> >
> > This really happens with __thread?  The right thing when this issue comes
> > up is to use __attribute__((nocommon)).
> 
> 
> This test case does indeed warn:
> 
>  __thread int errno __attribute__ ((nocommon));
> extern __thread int __libc_errno __attribute__ ((alias ("errno")));
> 
> with:
> test.i:2: warning: ^[$,1rx^[(B__libc_errno^[$,1ry^[(B aliased to undefined symbol ^[$,1rx^[(Berrno^[$,1ry
^[(B> 
> Initialising it to 0 fixes it,

Of course __attribute__ ((nocommon)) isn't meaningful with __thread.
__thread variables are never commons.  The question is why there is a
warning in the first place here.  AFAIK, there is no problem with an
uninitialized __thread variable getting an alias, except in the compiler's
mind.  

Re: Aliases ...

[Roland McGrath]

> If we need to, we can rearrange things such that aliases are 
> delayed until the real end of the translation unit, but...

This has always worked before, and initializing is ugly when you really
want bss symbols.

Re: Aliases ...

[Jakub Jelinek]

On Fri, Jan 14, 2005 at 11:30:15AM -0800, Roland McGrath wrote:
> > If we need to, we can rearrange things such that aliases are 
> > delayed until the real end of the translation unit, but...
> 
> This has always worked before, and initializing is ugly when you really
> want bss symbols.

That's a GCC4 bug that needs to be fixed there IMHO.

	Jakub

Re: Aliases ...

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

Jakub Jelinek <jakub@redhat.com> writes:

> On Fri, Jan 14, 2005 at 11:30:15AM -0800, Roland McGrath wrote:
>> > If we need to, we can rearrange things such that aliases are 
>> > delayed until the real end of the translation unit, but...
>> 
>> This has always worked before, and initializing is ugly when you really
>> want bss symbols.
>
> That's a GCC4 bug that needs to be fixed there IMHO.

Look at the email and bugreport that started this thread - RTH says
it's not a bug...

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Aliases ...

[Jakub Jelinek]

On Sat, Jan 15, 2005 at 08:19:16AM +0100, Andreas Jaeger wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > On Fri, Jan 14, 2005 at 11:30:15AM -0800, Roland McGrath wrote:
> >> > If we need to, we can rearrange things such that aliases are 
> >> > delayed until the real end of the translation unit, but...
> >> 
> >> This has always worked before, and initializing is ugly when you really
> >> want bss symbols.
> >
> > That's a GCC4 bug that needs to be fixed there IMHO.
> 
> Look at the email and bugreport that started this thread - RTH says
> it's not a bug...

That was talking about:
int errno;
extern  int __libc_errno __attribute__ ((alias ("errno")));

where I have no problems with gcc warning about it (although the
warning could warn instead about alias to common symbol).

But GCC warns even for:
int errno __attribute__((nocommon));
extern  int __libc_errno __attribute__ ((alias ("errno")));

and that is IMHO a bug.

	Jakub

Re: Aliases ...

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

Jakub Jelinek <jakub@redhat.com> writes:

> On Sat, Jan 15, 2005 at 08:19:16AM +0100, Andreas Jaeger wrote:
>> Jakub Jelinek <jakub@redhat.com> writes:
>> 
>> > On Fri, Jan 14, 2005 at 11:30:15AM -0800, Roland McGrath wrote:
>> >> > If we need to, we can rearrange things such that aliases are 
>> >> > delayed until the real end of the translation unit, but...
>> >> 
>> >> This has always worked before, and initializing is ugly when you really
>> >> want bss symbols.
>> >
>> > That's a GCC4 bug that needs to be fixed there IMHO.
>> 
>> Look at the email and bugreport that started this thread - RTH says
>> it's not a bug...
>
> That was talking about:
> int errno;
> extern  int __libc_errno __attribute__ ((alias ("errno")));
>
> where I have no problems with gcc warning about it (although the
> warning could warn instead about alias to common symbol).
>
> But GCC warns even for:
> int errno __attribute__((nocommon));
> extern  int __libc_errno __attribute__ ((alias ("errno")));
>
> and that is IMHO a bug.

Now I understood you.

Agreed - will you file a bugreport?

thanks,
Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Aliases ...

[Andreas Schwab]

Roland McGrath <roland@redhat.com> writes:

>> If we need to, we can rearrange things such that aliases are 
>> delayed until the real end of the translation unit, but...
>
> This has always worked before, and initializing is ugly when you really
> want bss symbols.

Although gcc should be able to notice that the initializer is all-zeroes
and place the variable in bss anyway.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."