Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!wjh12!talcott!harvard!seismo!brl-tgr!tgr!FIRTH@TL-20B.ARPA
From: FIRTH@TL-20B.ARPA
Newsgroups: net.unix-wizards
Subject: problems with -T option
Message-ID: <6199@brl-tgr.ARPA>
Date: Thu, 29-Nov-84 21:00:26 EST
Article-I.D.: brl-tgr.6199
Posted: Thu Nov 29 21:00:26 1984
Date-Received: Sun, 2-Dec-84 05:17:48 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 27

In the "ld" documentation of our 4.2/vax system, I find the -T option,
which says that it causes .text to begin at the given argument value,
rather than 0.

However, there are two problems.  First, the option cannot be passed through
"cc", failing with the loader message "too late, some text already loaded".
presumably this is because "cc" does not have the intelligence to realise
that -T must precede any .o file

The second problem is worse.  The linker seems to obey -T but the loader
(shell) seems to ignore it, and load the program at 0 anyway.  It is hard to
demonstrate this fact, since, evidently, any code that is not position
independent will crash disgustingly under such treatment, and, since the
standard libraries seem not to be position independent, test programs do
indeed crash disgustingly. 

You can observe the phenomenon though by writing a fragment like

	foo: movl $foo, r0
	     moval foo, r1

and observing in your favourite debugger that r0 holds what you think
it ought, ie the value relocated to take account of the -T option, and
r1 holds a value that takes no account of the -T option.

This is not a critical problem for us, but a fix would be appreciated.
-------