[PATCH 0/2] Define _edata, __bss_start, and _end only for executables

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Define various symbols conditionally in shared libraries executables

Alan Modra-3
On Tue, Jun 12, 2018 at 12:44:27PM +0100, Nick Clifton wrote:
> 2018-06-12  Nick Clifton  <[hidden email]>
>
> * emulparams/aarch64elf.sh (OTHER_BSS_END_SYMBOLS): Make the
> definition of the __bss_end__ symbol conditional upon CREATE_SHLIB.

Thanks for fixing this!  That reminds me, I was going to ask the
aarch64 maintainers to please reduce the duplication in the aarch64
emulparams files.  One way to do that is to choose one of them as the
base which others source and modify.

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: Define various symbols conditionally in shared libraries executables

Alan Modra-3
In reply to this post by Hans-Peter Nilsson
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
Reply | Threaded
Open this post in threaded view
|

Re: Define various symbols conditionally in shared libraries executables

Hans-Peter Nilsson
> Date: Tue, 12 Jun 2018 23:44:26 +0930
> From: Alan Modra <[hidden email]>

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

Hah, ![istarget cris-*-*].  Though, I believe there'd be too
many bit-patterns to tweak, so that has to stay.

> The cris-elf dump looks like:
>
> ld/tmpdir/libdso-1.so:     file format elf32-cris

Hm, this test runs for cris-elf?  DSOs don't make much sense
there...'k, apparently I set all required options to generate a
DSO, but apparently there's still a size difference.  The
purpose is to have cris-elf be the catch-all target.

> DYNAMIC SYMBOL TABLE:
> 000000d0 g    DF .text 00000002 dsofn
>
> So it would seem the patch should have made the address match
> 00000[01].[02468ace]

Right, though (IIRC) the purpose of the address pattern not
being ".+" is that I want to exclude 0 (and the last part is
that functions start on an even address).  Though, that doesn't
seem important enough to worry about.

Ok, thanks for clarifying; I'll fix.

brgds, H-P
Reply | Threaded
Open this post in threaded view
|

Re: Define various symbols conditionally in shared libraries executables

Hans-Peter Nilsson
> Date: Tue, 12 Jun 2018 16:47:35 +0200
> From: Hans-Peter Nilsson <[hidden email]>

> Right, though (IIRC) the purpose of the address pattern not
> being ".+" is that I want to exclude 0 (and the last part is
> that functions start on an even address).  Though, that doesn't
> seem important enough to worry about.

Still, this is what I committed.

ld:

        * testsuite/ld-cris/libdso-1.d: Correct recent address pattern update.

diff --git a/ld/testsuite/ld-cris/libdso-1.d b/ld/testsuite/ld-cris/libdso-1.d
index 2ad44af..5a7e9a1 100644
--- a/ld/testsuite/ld-cris/libdso-1.d
+++ b/ld/testsuite/ld-cris/libdso-1.d
@@ -4,10 +4,12 @@
 #objdump: -T
 
 # Just check that we actually got a DSO with the dsofn symbol.
+# The pattern also makes sure that the address (modulo 16) is non-zero
+# and even.
 
 .*:     file format elf32-cris
 
 DYNAMIC SYMBOL TABLE:
 #...
-000000.[02468ace] g    DF .text 0+2 dsofn
+0+[^0]+0*[02468ace] g    DF .text 0+2 dsofn
 #pass

brgds, H-P
12