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

[Alan Modra]

On Fri, Jun 01, 2018 at 11:45:32AM -0700, H.J. Lu wrote:
> On Wed, May 30, 2018 at 5:44 PM, Alan Modra <amodra@gmail.com> wrote:
> > On Wed, May 30, 2018 at 02:59:39PM -0700, H.J. Lu wrote:
> >> _edata, __bss_start, and _end are defined for executables.  FreeBSD's
> >> libc.so uses executable's _end to initialize curbrk.  But there is no
> >> good reason to access values of _edata, __bss_start, and _end defined
> >> in shared libraries.  We should define _edata, __bss_start, and _end
> >> only for executables.
> >
> > I agree with the idea, but the patch isn't complete.  You'll need to
> > look at all the target OTHER_END_SYMBOLS, OTHER_BSS_SYMBOLS, and
> > OTHER_BSS_END_SYMBOLS.  For instance, elf32mep.sh defines __heap = _end
> > in OTHER_END_SYMBOLS, which is going to go wrong when _end isn't
> > defined in a shared library..  Ah, no, mep uses its own mep.sc so
> > won't be affected by your elf.sc patch, but I'm sure you can see the
> > potential problem in other targets.  So please do look for _edata,
> > edata, __bss_start, _end and end in emulparams/*.sh.  A quick look
> > says this patch will likely cause fails on some targets, eg. see
> > elf32epiphany.sh EXECUTABLE_SYMBOLS.
> >
> > If you're lucky you might be able to wrap the occurrences of
> > OTHER_END_SYMBOLS, OTHER_BSS_SYMBOLS, OTHER_BSS_END_SYMBOLS and
> > EXECUTABLE_SYMBOLS in elf.sc with ${CREATE_SHLIB- }.
> >
> > Also, do test this sort of patch on a large set of ELF targets before
> > posting.
> >
> 
> The new set of patches are posted at
> 
> https://sourceware.org/ml/binutils/2018-06/msg00021.html

Did you do the analysis of emulparams files to see whether this is OK?

I suspect you may have taken my "If you're lucky" comment as meaning
to try that out and if there are no testsuite fails then the simple
approach is OK.  I meant that you should look at target usage of shell
variables like EXECUTABLE_SYMBOLS to see whether wrapping in
${CREATE_SHLIB-} make sense, and at least report back to the binutils
list about places where you are unsure.

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.

elf32_tic6x_le_sh has another odd use of EXECUTABLE_SYMBOLS,
presumably because R_C6000_SBR_* relocs have an implicit reference to
__c6xabi_DSBT_BASE.  I suspect those relocs can appear in shared
libraries.  So again something for the port maintainer, Joseph, to
comment on.  (The implicit reference would be better handled by
generating the reference explicitly on encountering these relocs in
check_relocs, I think, rather than just using OTHER_SYMBOLS.)

elf64hppa.sh might also need to define OTHER_SYMBOLS rather than
EXECUTABLE_SYMBOLS, if __SYSTEM_ID or _FPU_STATUS can be referenced
from shared libraries.  Dave?

-- 
Alan Modra
Australia Development Lab, IBM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-TIC6X-__c6xabi_DSBT_BASE.patch
Type: text/x-diff
Size: 2038 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20180602/788ff820/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-EXECUTABLE_SYMBOLS-OTHER_SYMBOLS.patch
Type: text/x-diff
Size: 2668 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20180602/788ff820/attachment-0001.bin>