lorder bug (doesn't see global ints).
Adam Quantrill
Apologies if someone has fixed this before, but here goes...
I've got the onerous task of porting some of our crashware from
its nice, safe home on 4.2BSD to horrible sysV (flame flame!! 8^).
Anyway, while creating the libraries, I noticed something was awry
(mainly 'cos the damn thing wouldn't compile!) and I narrowed the problem
down to the fact that lorder doesn't spot global ints when making its
dependency decisions. This is because nm flags these symbols as 'C'.
Here's the fix:
--------8><-------cut-here----------8><--------------
19c
/[TDC] /{
.
w
q
--------8><-------cut-here----------8><--------------
Run it via ed on the lorder shell script. If you use bss symbols (whatever
they are) you may wish to add a 'B' after the 'C' above. I've even put in the
w q for the lazy amongst us!
P.S. - Does this make me a wizard?
Guy Harris
> (mainly 'cos the damn thing wouldn't compile!) and I narrowed the problem
> down to the fact that lorder doesn't spot global ints when making its
> dependency decisions. This is because nm flags these symbols as 'C'.
That's odd:
1) System V has "ranlib" built into "ar", so the only thing "lorder" should
do is perhaps make "ld" run faster.
2) The 4.2BSD "lorder" has "/[TD] /" on line 19.
3) The System V, Release 2 "lorder" doesn't have "/[TD] /" anywhere in it,
and line 19 is in the middle of a comment.
Did you do the "lorder"ing on a 4.2 or an S5 machine? If the latter, you
don't have the S5 "lorder", and probably don't have the S5 object file
format. You might have "ranlib", though; try running "ranlib" on the
library. (There may, in fact, be a bug in "lorder" on 4.2, but not one that
causes problems since everybody "ranlib"s their libraries. I think that
"lorder" dates back to V7, which had a "ranlib" as well but didn't document
it and didn't use it on "libc".)
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com (or g...@sun.arpa)
Sam Kendall
>> Anyway, while creating the libraries, I noticed something was awry
>> (mainly 'cos the damn thing wouldn't compile!) and I narrowed the problem
>> down to the fact that lorder doesn't spot global ints when making its
>> dependency decisions. This is because nm flags these symbols as 'C'.
I (as s...@delftcc.UUCP) posted a fix to this a while ago, probably
sometime last year. I don't have the fix handy. Guy is right that
this bug shouldn't affect System V, although there really is a bug in
lorder.
On pre-COFF (AT&T Common Object File Format) UNIX systems, these are the
meanings of symbol types output by nm(1):
Letter Meaning C example
----- ------- ---------
U Undefined extern int i;
C Common (in the Fortran sense) int i;
D Definition int i = 5;
T Text f(){}
B BSS (initialized to 0) int i; after ld-ing
A 'C' symbol results from a noninitialized declaration of a global
variable. 'C' symbols appear only in relocatable object files. Here
are a the rules for how ld(1) combines 'C' symbols:
U* + C* + D => D
U* + C* => B
In other words, when any number of 'U's and 'C's combine with a 'D',
then the 'D' becomes the defining instance; but when any number of 'U's
and 'C's combine alone, the largest 'C' becomes the defining instance,
and the symbol is made into a 'B'.
The bug in lorder is that it recognizes only two classes of symbols for
the purposes of partial ordering: 'T' and 'D', and everything else.
But 'C' forms a middle class: symbols should be ordered 'U' first, then
'C', then 'T' or 'D'.
In putting the fix into lorder, you need to add a third temporary file,
and then run three joins instead of one.
---
Sam Kendall s...@godot.think.com
Thinking Machines Corp. ihnp4!think!sam