darkkirb/old-cross-binutils
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

* ldfile.c: Fix comment typos.

Browse source 
* ldlang.c: Likewise.
	* mri.c: Likewise.
	* pe-dll.c: Likewise.
This commit is contained in:
Kazu Hirata 2003-01-02 03:53:53 +00:00
parent 55ac548dfb
commit 396a246719
5 changed files with 21 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
ld/ChangeLog
View file

@ -1,3 +1,10 @@
2003-01-01 Kazu Hirata <kazu@cs.umass.edu>
* ldfile.c: Fix comment typos.
* ldlang.c: Likewise.
* mri.c: Likewise.
* pe-dll.c: Likewise.
2003-01-01 Daniel Jacobowitz <drow@mvista.com>
Suggested by Manfred Hollstein <manfred.h@gmx.net>:
@ -5,7 +12,7 @@
and ldver.texi.
* Makefile.in: Regenerated.
2002-12-24 Dmitry Diky <diwil@mail.ru>
2002-12-24 Dmitry Diky <diwil@mail.ru>
* Makefile.am: Add msp430 target.
* configure.tgt: Likewise.

2
ld/ldfile.c
View file

@ -402,7 +402,7 @@ try_open (name, exten)
}
/* Try to open NAME; if that fails, look for it in any directories
specified with -L, without and with EXTEND apppended. */
specified with -L, without and with EXTEND appended. */
FILE *
ldfile_find_command_file (name, extend)

10
ld/ldlang.c
View file

@ -523,7 +523,7 @@ new_statement (type, size, list)
or prefix it with a -l etc.
We can be supplied with requests for input files more than once;
they may, for example be split over serveral lines like foo.o(.text)
they may, for example be split over several lines like foo.o(.text)
foo.o(.data) etc, so when asked for a file we check that we haven't
got it already so we don't duplicate the bfd. */
@ -1304,7 +1304,7 @@ lang_add_section (ptr, section, output, file)
if (section->alignment_power > output->bfd_section->alignment_power)
output->bfd_section->alignment_power = section->alignment_power;
/* If supplied an aligment, then force it. */
/* If supplied an alignment, then force it. */
if (output->section_alignment != -1)
output->bfd_section->alignment_power = output->section_alignment;
@ -1700,7 +1700,7 @@ stricpy (dest, src)
*dest = 0;
}
/* Remove the first occurance of needle (if any) in haystack
/* Remove the first occurrence of needle (if any) in haystack
from haystack. */
static void
@ -2144,7 +2144,7 @@ lang_place_undefineds ()
}
}
/* Open input files and attatch to output sections. */
/* Open input files and attach to output sections. */
static void
map_input_to_output_sections (s, target, output_section_statement)
@ -3890,7 +3890,7 @@ lang_place_orphans ()
{
if (s->output_section == (asection *) NULL)
{
/* This section of the file is not attatched, root
/* This section of the file is not attached, root
around for a sensible place for it to go. */
if (file->just_syms_flag)

2
ld/mri.c
View file

@ -149,7 +149,7 @@ mri_draw_tree ()
/* Now build the statements for the ldlang machine. */
/* Attatch the addresses of any which have addresses,
/* Attach the addresses of any which have addresses,
and add the ones not mentioned. */
if (address != (struct section_name_struct *) NULL)
{

12
ld/pe-dll.c
View file

@ -59,7 +59,7 @@
code modifications).
2. This is done completely in bounds of the PE specification (to be fair,
there's a place where it pokes nose out of, but in practise it works).
there's a place where it pokes nose out of, but in practice it works).
So, resulting module can be used with any other PE compiler/linker.
3. Auto-import is fully compatible with standard import method and they
@ -74,7 +74,7 @@
The obvious and only way to get rid of dllimport insanity is to make client
access variable directly in the DLL, bypassing extra dereference. I.e.,
whenever client contains someting like
whenever client contains something like
mov dll_var,%eax,
@ -82,7 +82,7 @@
DLL. The aim is to make OS loader do so, and than make ld help with that.
Import section of PE made following way: there's a vector of structures
each describing imports from particular DLL. Each such structure points
to two other parellel vectors: one holding imported names, and one which
to two other parallel vectors: one holding imported names, and one which
will hold address of corresponding imported name. So, the solution is
de-vectorize these structures, making import locations be sparse and
pointing directly into code. Before continuing, it is worth a note that,
@ -104,7 +104,7 @@
above: PE specification rambles that name vector (OriginalFirstThunk)
should run in parallel with addresses vector (FirstThunk), i.e. that they
should have same number of elements and terminated with zero. We violate
this, since FirstThunk points directly into machine code. But in practise,
this, since FirstThunk points directly into machine code. But in practice,
OS loader implemented the sane way: it goes thru OriginalFirstThunk and
puts addresses to FirstThunk, not something else. It once again should be
noted that dll and symbol name structures are reused across fixup entries
@ -115,7 +115,7 @@
in windows9x kernel32.dll, so if you use it, you have two
IMAGE_IMPORT_DESCRIPTORS for kernel32.dll). Yet other question is whether
referencing the same PE structures several times is valid. The answer is why
not, prohibitting that (detecting violation) would require more work on
not, prohibiting that (detecting violation) would require more work on
behalf of loader than not doing it.
See also: ld/emultempl/pe.em. */
@ -2627,7 +2627,7 @@ pe_implied_import_dll (filename)
imp = def_file_add_import (pe_def_file, erva + name_rva,
dll_name, i, 0);
/* Mark symbole type. */
/* Mark symbol type. */
imp->data = is_data;
if (pe_dll_extra_pe_debug)