Re: [PATCH 1/2] ld: Define _edata, __bss_start, and _end only for executables

[Alan Modra <amodra at gmail dot com>]

On Wed, Jun 06, 2018 at 05:10:48PM +0100, Maciej W. Rozycki wrote:
> On Sat, 2 Jun 2018, Alan Modra wrote:
> 
> > For EXECUTABLE_SYMBOLS, it's fairly obvious that your patch will break
> > elf64bmip.sh since it defines symbols inside ${CREATE_SHLIB+}.  That
> > emulparams file should probably be using OTHER_SYMBOLS instead.
> > elf32bmipn32.sh is also a worry, and likely should be using
> > OTHER_SYMBOLS with the same sort of expression as elf64bmip.sh but
> > adjusted for 32-bit header size.  I'm unsure about elf32b4300.sh but
> > my guess is it will be OK to only define _DYNAMIC_LINK for
> > executables.  This doesn't mean you need to fix these MIPS problems
> > yourself, just raise them with Maciej.  Of course, if you like,
> > provide a patch like the ones I've attached.
> 
>  My understanding is that replacing EXECUTABLE_SYMBOLS with OTHER_SYMBOLS 
> would make the symbols created section-relative rather than absolute, 
> which is likely the reason why EXECUTABLE_SYMBOLS has been (ab)used like 
> this.

No, OTHER_SYMBOLS generally defines absolute symbols since it isn't
expanded inside an output section statement.  Looking at one of the ld
testsuite output files for mips-sgix-irix6, I see

../binutils/nm-new tmpdir/pr22471
100102a8 D __bss_start
00000000 A __dso_displacement
10000160 r _DYNAMIC
100102a8 D _edata
10000000 A __elf_header
100102a8 D _end
100102a8 D _fbss
10010290 D _fdata
10000280 T _ftext
100102a0 D _GLOBAL_OFFSET_TABLE_
10018290 d _gp
10000280 T main
10000034 A __program_header_table
10010290 A __rld_map
10000280 T start
10000280 T _start
10000280 T __start

You'd run into problems if the expressions used to define the symbols
changed from near the start of the script where EXECUTABLE_SYMBOLS is
expanded to near the end where OTHER_SYMBOLS is expanded, or if the
script used DEFINED (__elf_header) say.  None of that happens, so I
think the change is safe.

>  The current usage comes from commit 786dbcc3f49a ("Linking n64 code for 
> irix (part 1/2)"), 
> <https://sourceware.org/ml/binutils/2003-10/msg00274.html>, which 
> unfortunately has not been further justified in the review (as has not 
> been why n32 had not been updated accordingly; it seems wrong as it 
> stands).

OK, I'll go ahead with the commit.

>  Older commits in this area do not provide any further 
> explaination either; these are commit 22c675a780d5 ("PATCH to enable GNU 
> ld on MIPS 64-bit ABI"), 
> <https://sourceware.org/ml/binutils/1999-q3/msg00073.html>, and commit 
> dc8319788003 ("PATCH for enabling IRIX6 ld"), 
> <https://sourceware.org/ml/binutils/1999-q2/msg00385.html>.
> 
>  How about defining an ABSOLUTE_SYMBOLS parameter then and placing it next 
> to EXECUTABLE_SYMBOLS for symbols that need to be there whether in an 
> executable or in a DSO?  Or maybe SHLIB_SYMBOLS for DSO use only, so that 
> ${CREATE_SHLIB+/-} qualification is not locally needed?
> 
>   Maciej

-- 
Alan Modra
Australia Development Lab, IBM