Re: Define various symbols conditionally in shared libraries executables

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> Date: Wed, 6 Jun 2018 22:00:43 +0930
> From: Alan Modra <amodra@gmail.com>

> This should be applied on top of the patches attached to
> https://sourceware.org/ml/binutils/2018-06/msg00034.html
> 
> The values of symbols in shared libraries like _end, _edata, and
> __bss_start are generally not that useful outside of the shared
> library.  This patch defines them conditionally with PROVIDE, since a
> shared library might need the local value.  An example is glibc ld.so
> local access to "_begin", "_etext" and "_end".  We can't use
> PROVIDE_HIDDEN because the shared library might need the value of the
> symbol in the executable.  An example is freebsd libc dynamic access
> to "_end".

Thanks for adjusting the testsuites, but...

> 	PR ld/23161
[...]
> 	* testsuite/ld-cris/libdso-1.d,
[...]
> : Update.

> diff --git a/ld/testsuite/ld-cris/libdso-1.d b/ld/testsuite/ld-cris/libdso-1.d
> index aa41d4f1d7..2ad44af2c4 100644
> --- a/ld/testsuite/ld-cris/libdso-1.d
> +++ b/ld/testsuite/ld-cris/libdso-1.d
> @@ -9,5 +9,5 @@
>  
>  DYNAMIC SYMBOL TABLE:
>  #...
> -00000[12].[02468ace] g    DF .text	0+2 dsofn
> +000000.[02468ace] g    DF .text	0+2 dsofn
>  #pass

Are you sure about this?  For me and my autotester, this change
caused, for --target=cris-axis-linux-gnu:

Running X/src/ld/testsuite/ld-cris/cris.exp ...
FAIL: ld-cris/libdso-1

I had a hunch it could be a 32- vs. 64-bit difference even
though cris-* is 64-bit-bfd everywhere now, but the dump.out
file for me has the following contents for both 64- and 32-bit
hosts:

tmpdir/dump:     file format elf32-cris

DYNAMIC SYMBOL TABLE:
00000104 l    d  .text	00000000 .text
00000104 g    DF .text	00000002 dsofn

So, perhaps a spurious change?  Or something else remaining to
be committed?  Reverting the quoted part returns results to
all-passing.

brgds, H-P