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

["Maciej W. Rozycki" <macro at mips dot com>]

On Wed, 6 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.

 Right, I didn't look carefully enough: moving the definitions to 
OTHER_SYMBOLS will place them within a SECTIONS command rather than at the 
outer level, however not in an output section definition.  So no change in 
absolute vs section-relative semantics here indeed.

 NB I find this LD manual paragraph confusingly unclear:

   "Some terms in linker expressions are addresses.  This is true of
section relative symbols and for builtin functions that return an
address, such as `ADDR', `LOADADDR', `ORIGIN' and `SEGMENT_START'.
Other terms are simply numbers, or are builtin functions that return a
non-address value, such as `LENGTH'.  One complication is that unless
you set `LD_FEATURE ("SANE_EXPR")' (*note Miscellaneous Commands::),
numbers and absolute symbols are treated differently depending on their
location, for compatibility with older versions of `ld'.  Expressions
appearing outside an output section definition treat all numbers as
absolute addresses.  Expressions appearing inside an output section
definition treat absolute symbols as numbers.  If `LD_FEATURE
("SANE_EXPR")' is given, then absolute symbols and numbers are simply
treated as numbers everywhere."

While I've figured out from elsewhere what the intent is, i.e. that 
depending on `SANE_EXPR' numbers inside an output section definition are 
considered either section-relative addresses (offsets) or absolute 
addresses (constants) ("absolute address" is arguably a misnomer here, but 
we've used it traditionally, so I think it's acceptable with a suitable 
glossary entry), I'm afraid it's all but clear to the casual reader.  I 
find the overloading of the definition of a number particularly confusing 
here.

 I can try making it clearer unless you'd rather did it yourself -- WDYT?

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

 Agreed.

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

 Actually I missed the presence of attachments with patches you included.  
I see now that you have fixed the n32 IRIX emulation parameters to match 
the n64 counterparts.  Thank you.

 As to `elf32b4300.sh' I think the definition can actually go, following:

commit 53787b2316b0e9b4f166efc87f88748c46263096
Author: Ian Lance Taylor <ian@airs.com>
Date:   Mon Jan 29 20:01:29 1996 +0000

whose ChangeLog does not match, as we've seen before, and which likely 
comes from:

Thu Jan 11 11:23:30 1996  Ian Lance Taylor  <ian@cygnus.com>

	* elf32-mips.c: Extensive changes for a start at dynamic linking
	support, from Kazumoto Kojima <kkojima@info.kanagawa-u.ac.jp>.

Said commit clearly has obsoleted that definition, which has been since 
handled within BFD, which nobody noticed, perhaps because its presence in 
`elf32b4300.sh' is harmless.  The emulation is used by a bunch of 
bare-metal MIPS `configure.tgt' targets, coming from:

commit 751b7dcc00ada9869d445efb0df51a73bc44d8ed
Author: Jackie Smith Cashion <jsmith@redhat.com>
Date:   Fri Sep 1 15:38:07 1995 +0000

    NEC VR4300 target (IDT SIM monitor) support.

which we might be able to obsolete.  However for the time being I'm 
inclined to just drop the definition.

 Thanks for your input.  I have no objections to your patches.

  Maciej