Fix resolver bind, getsockname namespace (bug 17733)

  On Linux architectures using socketcall, the resolver ends up bringing
in strong symbols for bind and getsockname, which are not in
POSIX.1-1996.  This causes linknamespace test failures:

FAIL: conform/POSIX/pthread.h/linknamespace
FAIL: conform/POSIX/sched.h/linknamespace
FAIL: conform/POSIX/time.h/linknamespace

These functions are defined as strong symbols with __bind and
__getsockname as weak aliases.  This patch switches this to the other
way round by removing the NO_WEAK_ALIAS definitions and so letting the
default case in socket.S act; I see no reason for the existing
arrangements.

Tested for x86 (testsuite, and that disassembly of installed shared
libraries is unchanged by the patch).

2014-12-19  Joseph Myers  <joseph@codesourcery.com>

	[BZ #17733]
	* sysdeps/unix/sysv/linux/bind.S (NO_WEAK_ALIAS): Do not define.
	(__bind): Do not define as weak alias.
	* sysdeps/unix/sysv/linux/getsockname.S (NO_WEAK_ALIAS): Do not
	define.
	(__getsockname): Do not define as weak alias.
  

On Fri, Dec 19, 2014 at 10:56 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Linux architectures using socketcall, the resolver ends up bringing
> in strong symbols for bind and getsockname, which are not in
> POSIX.1-1996.  This causes linknamespace test failures:
>
> FAIL: conform/POSIX/pthread.h/linknamespace
> FAIL: conform/POSIX/sched.h/linknamespace
> FAIL: conform/POSIX/time.h/linknamespace
>
> These functions are defined as strong symbols with __bind and
> __getsockname as weak aliases.  This patch switches this to the other
> way round by removing the NO_WEAK_ALIAS definitions and so letting the
> default case in socket.S act; I see no reason for the existing
> arrangements.
>
> Tested for x86 (testsuite, and that disassembly of installed shared
> libraries is unchanged by the patch).
>
> 2014-12-19  Joseph Myers  <joseph@codesourcery.com>
>
>         [BZ #17733]
>         * sysdeps/unix/sysv/linux/bind.S (NO_WEAK_ALIAS): Do not define.
>         (__bind): Do not define as weak alias.
>         * sysdeps/unix/sysv/linux/getsockname.S (NO_WEAK_ALIAS): Do not
>         define.
>         (__getsockname): Do not define as weak alias.
>
> diff --git a/sysdeps/unix/sysv/linux/bind.S b/sysdeps/unix/sysv/linux/bind.S
> index 7719ad0..61fb5eb 100644
> --- a/sysdeps/unix/sysv/linux/bind.S
> +++ b/sysdeps/unix/sysv/linux/bind.S
> @@ -1,5 +1,3 @@
>  #define        socket  bind
>  #define        NARGS   3
> -#define NO_WEAK_ALIAS  1
>  #include <socket.S>
> -weak_alias (bind, __bind)
> diff --git a/sysdeps/unix/sysv/linux/getsockname.S b/sysdeps/unix/sysv/linux/getsockname.S
> index 9ea371f..c138be9 100644
> --- a/sysdeps/unix/sysv/linux/getsockname.S
> +++ b/sysdeps/unix/sysv/linux/getsockname.S
> @@ -1,5 +1,3 @@
>  #define        socket  getsockname
>  #define        NARGS   3
> -#define NO_WEAK_ALIAS  1
>  #include <socket.S>
> -weak_alias (getsockname, __getsockname)
>

Looks good to me.

Do sysdeps/unix/sysv/linux/listen.S and sysdeps/unix/sysv/linux/setsockopt.S
have the same issue?  Does the linknamespace test check them?

Thanks.
  

On Sun, 21 Dec 2014, H.J. Lu wrote:

> Do sysdeps/unix/sysv/linux/listen.S and sysdeps/unix/sysv/linux/setsockopt.S
> have the same issue?  Does the linknamespace test check them?

I don't see any linknamespace test failures (even XFAILed) mentioning 
those functions.  That is, there seem to be no cases (for the standards 
currently tested, at least) of a function in a standard lacking those 
functions calling listen / setsockopt, or calling __listen / __setsockopt 
and thereby bringing in strong symbols for listen / setsockopt.

Thus, while I think a corresponding change to those files would make sense 
as a cleanup, it would not fix a user-visible bug (and so would not need a 
bug filed in Bugzilla).