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

[Maciej W. Rozycki]

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.

 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).  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