With jb's rev 1.2 commit to usr.bin/lorder/lorder.sh we don't depend on
the 4.4BSD's ``nm -o'' behavior.
Previous to 4.3BSD-Reno, ``nm -o'' did not output the .o's filename on a
line by itself. The change occurred between CSRG's nm.c rev 4.8 (1987) and
rev 5.1 (in 1989), which was "new version from Hans Huebner hans@garp.mit.edu,
huebner@db0tui6.BITNET". The Binutils maintainers would rather cater to
a loud boisterous user of 4.3BSD VAXen which has its own native toolchain,
rather than a modern Unix with multiple orders of magnitude more users
and in which Binutils *is* the native toolchain.
I did not catch this on the EGCS 1.1.x --> GCC 2.95 upgrade.
So propogate this change to our custom hacks.
PR: 15549
Submitted by: Naohiko Tsuji <yakisoba@osaka.interq.or.jp>
Patrick Bihan-Faou <patrick@mindstep.com>
maintainers.
After we established our branding method of writing upto 8 characters of
the OS name into the ELF header in the padding; the Binutils maintainers
and/or SCO (as USL) decided that instead the ELF header should grow two new
fields -- EI_OSABI and EI_ABIVERSION. Each of these are an 8-bit unsigned
integer. SCO has assigned official values for the EI_OSABI field. In
addition to this, the Binutils maintainers and NetBSD decided that a better
ELF branding method was to include ABI information in a ".note" ELF
section.
With this set of changes, we will now create ELF binaries branded using
both "official" methods. Due to the complexity of adding a section to a
binary, binaries branded with ``brandelf'' will only brand using the
EI_OSABI method. Also due to the complexity of pulling a section out of an
ELF file vs. poking around in the ELF header, our image activator only
looks at the EI_OSABI header field.
Note that a new kernel can still properly load old binaries except for
Linux static binaries branded in our old method.
*
* For a short period of time, ``ld'' will also brand ELF binaries
* using our old method. This is so people can still use kernel.old
* with a new world. This support will be removed before 5.0-RELEASE,
* and may not last anywhere upto the actual release. My expiration
* time for this is about 6mo.
*
-fpic code that damages symbol locations at runtime.
The only know occurance in our tree (src and ports) was locatime.c,
which was just changed to generate code that doesn't trigger the
problem.
This is a workaround, the real cause is that our gas doesn't
understand code our gcc generates for some -O -fpic code. They are
expected to be back in sync soon, but until then (including
4.0-RELEASE) we need to prevent people from using bad -fpic code.
PR: avoids such things as in bin/16862
Submitted by: bde
Approved by: jkh
