Re: port-macppc/47464: cannot run older programs (around 2005/2006 time frame) due to undefined symbols _SDA_BASE_ and _SDA2_BASE_

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

The following reply was made to PR port-macppc/47464; it has been noted by GNATS.

From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-macppc/47464: cannot run older programs (around 2005/2006
 time frame) due to undefined symbols _SDA_BASE_ and _SDA2_BASE_
Date: Tue, 25 Apr 2017 21:01:57 +0300

 On Mon, Apr 24, 2017 at 14:33:58 +0200, Christian Groessler wrote:
 
 > I've now tried with 2.0.
 > 
 > Problem happens with a simple "hello world" program, too. Probably also on
 > 3.1 (I hadn't tested that then).
 > 
 > --- on 2.0 ---
 > $  uname -a
 > NetBSD power3 2.0 NetBSD 2.0 (GENERIC) #0: Wed Dec  1 14:03:55 UTC 2004 builds@build:/big/builds/ab/netbsd-2-0-RELEASE/macppc/200411300000Z-obj/big/builds/ab/netbsd-2-0-RELEASE/src/sys/arch/macppc/compile/GENERIC
 > macppc
 > $  cat hello.c
 > #include <stdio.h>
 > 
 > int main(void)
 > {
 >         printf("hello.c\n");
 >         return(0);
 > }
 > $  cc -o hello hello.c
 > $  ./hello
 > hello.c
 > $
 > ---------
 > 
 > my -current system is still from dec-31-2016:
 > 
 > --- -current ----
 > $ ./hello
 > Undefined symbol "_SDA2_BASE_" referenced from COPY relocation in ./hello
 > $
 > ----------------
 
 This is probably a fallout from binutils upgrade.  The following
 binutils bug looks like it might be related:
 
 https://sourceware.org/bugzilla/show_bug.cgi?id=16952
 PowerPC LD requests bug report. Issue related to EABI symbols _SDA_BASE_, _SDA2_BASE_
 
 _SDA_BASE_ is the "base" address for .sdata, "small" data, section.
 The whole .sdata section can be addressed with a 16-bit signed offset
 from _SDA_BASE_ (ditto for _SDA2_BASE_ for .sdata2, which I'm going to
 omit from now on).
 
 For COPY relocs linker and libraries guide explains
 https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter4-84604/index.html
 
 | Suppose the link-editor is used to create a dynamic executable, and
 | a reference to a data item is found to reside in one of the
 | dependent shared objects. Space is allocated in the dynamic
 | executable's .bss, equivalent in size to the data item found in the
 | shared object. This space is also assigned the same symbolic name as
 | defined in the shared object. Along with this data allocation, the
 | link-editor generates a special copy relocation record that
 | instructs the runtime linker to copy the data from the shared object
 | to the allocated space within the dynamic executable.
 | 
 | Because the symbol assigned to this space is global, it is used to
 | satisfy any references from any shared objects. The dynamic
 | executable inherits the data item. Any other objects within the
 | process that make reference to this item are bound to this copy. The
 | original data from which the copy is made effectively becomes
 | unused.
 
 So from my limited understanding the problem is that it doesn't even
 make sense for the main executable to have COPY relocs for _SDA_BASE_.
 
 Old binaries built with buggy binutils do have such bogus relocs
 though.  They used to be satisfied by ld.so from _SDA_BASE_ of the
 first dynamic library the main program depends on.  On a newer system
 the dynamic libs don't have _SDA_BASE_, hence the error you see.
 
 E.g. copy the old libc.so.12 onto your current system and run
 
   $ ./hello
   Undefined symbol "_SDA_BASE_" referenced from COPY relocation in ./hello
   $ LD_LIBRARY_PATH=$PWD ./hello # with old ./libc.so.12
   hello, world
 
 
 I'm not sure what a good fix for this would be.  May be a ppc-specific
 hack in ld.so that detects bogus COPY relocs for _SDA_BASE_ and treats
 them specially?
 
 -uwe