[net.lang.c] ld - the link editor

bruce@graffiti.UUCP (Bruce Jilek) (01/07/86)

Having just read a very long and dry description of the ld(1) Link
Editor for the AT&T Unix PC, I was impressed by the fact that there
are so many features not covered in the man pages on it.

My question is...why do you want to control the link process in that
way.  For example, why would you want to change the entry point for a program,
or other such subtle memory allocation features.  Are there any "easy to
identify with" reasons, or is this a remnant from days gone by when Unix
was an academic subject only.

freak@nsc.UUCP (Curt Mayer) (01/09/86)

In article <106@graffiti.UUCP> bruce@graffiti.UUCP (Bruce Jilek) writes:
>Having just read a very long and dry description of the ld(1) Link
>Editor for the AT&T Unix PC, I was impressed by the fact that there
>are so many features not covered in the man pages on it.
>
>My question is...why do you want to control the link process in that
>way.  For example, why would you want to change the entry point for a program,
>or other such subtle memory allocation features.  Are there any "easy to
>identify with" reasons, or is this a remnant from days gone by when Unix
>was an academic subject only.

yep. sure are. have you ever heard of embedded applications? that's where you
have a micro (say a 68k or something) controlling some thingy (like a toaster).
if i have my memory map in this toaster screwed by the hardware designers, then
i need to be able to load text over here in rom, and data and bss way over there
in ram. get the idea? by the way, this is very, very common.

	but, it makes the cat throw up.

	curt mayer

ark@alice.UucP (Andrew Koenig) (01/09/86)

> My question is...why do you want to control the link process in that
> way.  For example, why would you want to change the entry point for a program,
> or other such subtle memory allocation features.  Are there any "easy to
> identify with" reasons, or is this a remnant from days gone by when Unix
> was an academic subject only.

Features of this sort in linkers are often crucial when
using the linker to build an operating system kernel.

jsdy@hadron.UUCP (Joseph S. D. Yao) (01/09/86)

The link editor is a much more versatile program than most people
give it credit for or even (including me) can understand.  Many of
its features are for curious systems-programming use, like providing
non-standard entry points for stand-alone programs, or curdling
memory models on odd machines.  If its use were only for linking
C applications programs, we would make the options the C compiler
uses standard, and then not have any more, no?
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}

mats@fortune.UUCP (Mats Wichmann) (01/09/86)

If I am not mistaken, the linke editor referred to is the new (COFF) one,
which actually has many more features than the old ones used to (so this
is not "a holdover from the old days"). All of this stuff is of no
use to the average UNIX user, who just gets the default conditions
(stored in a file called default.ld). On the other hand, all of the
control is very useful if you are cross-compiling programs for target
machines, especially ones with strange memory requirements. It is
no longer necessary to have a special copy of "ld" compiled for
that machine that requires data to start on a 2meg boundary, when
the host machine defaults to a 256k boundary, to make up a fictitious
example. All you do is supply a different loader command file.
As I say, not much use to most people, but I'm not complaining!!!

    Mats Wichmann
    Fortune Systems
    {ihnp4,hplabs,dual}!fortune!mats

preece@ccvaxa.UUCP (01/10/86)

The entry point switch is also useful if you're doing overlay (-A)
loading and need to tell the loader where the new code is supposed
to go in your image.

-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece@gswd-vms

gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/11/86)

> My question is...why do you want to control the link process in that
> way.  For example, why would you want to change the entry point for a program,
> or other such subtle memory allocation features.  Are there any "easy to
> identify with" reasons, or is this a remnant from days gone by when Unix
> was an academic subject only.

For routine use as a timesharing user, you do not need such features.
(The 6th Edition UNIX "ld" was very simple.)  However, if you're
building code to be burned into ROMs, trying to link to support
routines at predetermined addresses (shared libraries or 5620 DMD
downloaded code, for example), or other such "unusual" activities,
the extra linker flexibility can be quite important.

carl@hpcnof.UUCP (01/12/86)

> Don't laugh, there really exist electric toasters which claim to be
> controlled by microchip, I've got one.

Yes, but what happens when it says "ERROR 2" and starts dumping the stack
in octal?  It may have burned the toast, but at least you have all the
information to sift through the ashes.

Ah, but software can fix anything!

;-))



Carl Dierschow
HP-CNO

mash@mips.UUCP (John Mashey) (01/12/86)

In article <106@graffiti.UUCP> bruce@graffiti.UUCP (Bruce Jilek) writes:
> Editor for the AT&T Unix PC, I was impressed by the fact that there
> My question is...why do you want to control the link process in that
> way.  For example, why would you want to change the entry point for a program,
> or other such subtle memory allocation features.  Are there any "easy to
> identify with" reasons, or is this a remnant from days gone by when Unix
> was an academic subject only.
1) Kernels in general like to have a different entry point than
user programs, and quite different layouts.
2) Much of what's in ld & COFF came from needs of BTL people building
ESS systems and others that needed this control.  It hardly came from
the academic side [or even the general time-sharing side.]
-- 
-john mashey
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD:  	415-960-1200
USPS: 	MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043

caag@rlvd.UUCP (Crispin Goswell) (01/13/86)

In article <3374@nsc.UUCP> freak@nsc.UUCP (Curt Mayer) writes:
>have you ever heard of embedded applications? that's where you
>have a micro (say a 68k or something) controlling some thingy (like a toaster).
>if i have my memory map in this toaster screwed by the hardware designers...

Don't laugh, there really exist electric toasters which claim to be controlled
by microchip, I've got one. It makes good toast (except on Tuesday nights when
there's a full moon...)

    Crispin Goswell

jsdy@hadron.UUCP (Joseph S. D. Yao) (01/22/86)

In article <48300001@hpcnof.UUCP> carl@hpcnof.UUCP writes:
>> Don't laugh, there really exist electric toasters which claim to be
>> controlled by microchip, I've got one.
>Yes, but what happens when it says "ERROR 2" and starts dumping the stack
>in octal?  It may have burned the toast, but at least you have all the
>information to sift through the ashes.
>Ah, but software can fix anything!

I assume this is in re the famous toaster for which Larry Isley
of W.E.  said (ten years ago) that you could buy a Unix license?
[;-)]
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}