Define various symbols conditionally in shared libraries executables

[Alan Modra]

On Tue, Jun 12, 2018 at 05:37:03AM +0200, Hans-Peter Nilsson wrote:
> > 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.

I test cris-elf, which needed a change, and crisv32-linux.  On looking
at my logs I see the libdso-1 test wasn't run for the linux target..
In fact, none of the ld-cris/ tests were run, for a fairly obvious
reason.

The cris-elf dump looks like:

ld/tmpdir/libdso-1.so:     file format elf32-cris

DYNAMIC SYMBOL TABLE:
000000d0 g    DF .text	00000002 dsofn

So it would seem the patch should have made the address match
00000[01].[02468ace]

-- 
Alan Modra
Australia Development Lab, IBM