_why_ does the UNIX linker not distinguish text and data addresses???
2656-Daniel R. Levy00000000000
levy at mtcchi.uucp
Mon Jul 30 20:47:26 AEST 1990
Compile these two files together on a UNIX system:
::::::::::::::
a.c
::::::::::::::
main()
{
(void) bogus();
return 0;
}
::::::::::::::
b.c
::::::::::::::
int bogus;
$ cc -o ab a.c b.c
a.c:
b.c:
Linking:
$ ./ab
Illegal instruction - core dumped
So far I have tried this on a 3B2 (SVR3.1), a Sun4 (SunOS 4.0.3), and an
Amdahl (UTS 5.2.6b). All compile and link similarly quietly.
Now my question is, why does the linker silently resolve the function reference
to the global variable without even a whisper of a warning? Or, to partially
answer my own question, why doesn't the compiler put something in the symbol
table for a.c saying "hey, I expect 'bogus' to be a text address"? (True,
this is obvious from the use of the symbol in the code, but the linker doesn't
examine the code, it just patches it according to the symbol table, right?)
Yes I know this is a stupid thing to do, I'm just asking hypothetically.
"lint" does identify the problem though in the same rather generic terms
("value type declared inconsistently") that it applies to more harmless
discrepancies between closely related datatypes.
True, the linker has to allow for tricks such as putting the strings of a
program into text space through diddling of the assembly (to cut down
on data space, which is not shared among processes) and dynamic linking of
code. But why can't there be special assembler directives for these so the
linker can still catch boo-boos like that illustrated?
--
Daniel R. Levy * Memorex Telex * Naperville IL * ..!uunet!tellab5!mtcchi!levy
So far as I can remember, there is not one ... therefore be ye as shrewd
word in the Gospels in praise of intelligence. as serpents <Gen. 3> and harm-
-- Bertrand Russell [Berkeley UNIX fortune] less as doves -- God [MT. 10:16]
More information about the Comp.unix.questions
mailing list