src/gnu/usr.bin/ld/ld.c, branch release/2.2.8_cvs

This commit was manufactured by cvs2svn to create tag

1999-01-21T00:55:30+00:00

'RELENG_2_2_8_RELEASE'.

This commit was manufactured to restore the state of the 2.2.8-RELEASE image.
Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs.

Sync with -current.

1997-08-08T02:18:14+00:00

Merge two bug fixes from main branch:

1997-02-03T00:50:35+00:00

    Use xmalloc instead of malloc:
        ld.c            1.38 -> 1.39
        support.c       1.2  -> 1.3

    Fix miscounting of N_INDR (alias) symbols:
        ld.c            1.39 -> 1.40

Support for .weak (in addition to the N_INDR stab) for gcc/g++. Also deal

1996-10-01T01:22:51+00:00

with the -R option and store the path in the dynamic header when specified.
The $LD_RUN_PATH environment variable is not checked yet.

While here, split up the code a bit more to enable more selective replacing
of GPL'ed components that are linked with ld.so with others.

Obtained from: NetBSD (mostly, the breakup is my fault)

General -Wall warning cleanup, part I.

1996-07-12T19:08:36+00:00

Submitted-By: Kent Vander Velden

Aw c'mon. I'm being driven mad by plenty of other things. I don't

1996-06-08T04:52:57+00:00

need this.

Consider the following code:

	case 'O':
		output_filename = malloc(strlen(arg)+4);
		strcpy(output_filename, arg);
		strcat(output_filename, ".tmp");
		real_output_filename = arg;
		return;

The idea here is to malloc() a buffer big enough to hold the name of
a supplied file name, plus ".tmp". So we malloc() 'size of filename'
bytes plus 4, right? Wrong! ".tmp" is _FIVE_ bytes long! There's a
traling '\0' which strcat() gleefully tacks on _outside_ the bounds
of the buffer. Result: program corrupts own memory. Program SEGVs at
seemingly random times. Bill not like random SEGVs. Bill smash.

Know how I found this? I've been trying to bootstrap -current on my
2.1.0-RELEASE machine at work and I couldn't seem to get libc.a built
because the linker would intermittently blow chunks while executing
things like 'ld -O foo.o -X -r foo.o'. Since this is an initial
bootstrap version of ld, it was linked against the 2.1.0 libc, who's
malloc() behaves differently than that in -current.

Presumeably ld -O doesn't blow up in -current, otherwise someone would
have spotted this already. I don't know if this is a bug or a feature.

Anyway. I'm changing the strlen(arg)+4 to strlen(arg)+5. Bah.

Add an option -O to ld. From the manpage:

1996-05-28T16:17:48+00:00

     -O filename
             Specifies the name of the output file.  The file is created as
             filename.tmp and when output is complete renamed to filename.
This allows us to:
	ld -O ${.TARGET} -x -r ${.TARGET}

When a local symbol that would normally be eliminated by "-x" or

1996-04-24T23:31:08+00:00

"-X" must survive, because of references from relocations, don't
qualify the symbol name with the name of the input file.  This
saves some string space.  It makes libc_pic.a about 2.4% smaller.

Adapted from a suggestion by Bruce Evans.

Remove LD_NOSTD_PATH implementation, it isn't works and

1995-10-24T06:48:16+00:00

can cause some problems.
Suggested-by: davidg

Fix checks for open() failing. open() may successfully return 0.

1995-09-28T19:43:22+00:00

ld.c:
Fix a an error message that said that open() failed after fopen() failed.