lorder bug (doesn't see global ints).
Sam Kendall
sam at think.COM
Sat Aug 23 02:02:43 AEST 1986
In article <6425 at sun.uucp> guy at sun.uucp (Guy Harris) writes:
>> 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 sam at 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 sam at godot.think.com
Thinking Machines Corp. ihnp4!think!sam
More information about the Net.bugs
mailing list