[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-macppc/47464: cannot run older programs (around 2005/2006 time frame) due to undefined symbols _SDA_BASE_ and _SDA2_BASE_
The following reply was made to PR port-macppc/47464; it has been noted by GNATS.
From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
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
> $ cat hello.c
> #include <stdio.h>
> int main(void)
> $ cc -o hello hello.c
> $ ./hello
> 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:
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
| 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
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
Undefined symbol "_SDA_BASE_" referenced from COPY relocation in ./hello
$ LD_LIBRARY_PATH=$PWD ./hello # with old ./libc.so.12
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
Main Index |
Thread Index |