⟦a20178b3f⟧

TextFile



Indhold.

 1. Introduktion.
 2. Funktioner.
 3. Objektmodul-formatet.
 4. Loadmodul-formatet.
 5. Hovedalgoritme og -datastrukturer.


1. Introduktion.

     På et møde d. 12.10.1984 enedes vi om at opgive at fremstille en
assembler, som skulle benyttes som bagende til EOS-pascal- og C-
oversætterne. I stedet satser vi nu på at lade oversætterne generere
objektkoden direkte i relokerbar form, fordi dette skønnes at være
hurtigere at udvikle. Hermed nødvendiggøres en specifikation af grænse-
fladen til linkeren, og udviklingen af linkeren i sig selv er tillige
blevet aktuel, fordi denne ikke forudsætter adgang til dokumentation, som
ikke er tilgængelig. Ambitionen er hurtigt at udvikle en simpel linker,
som netop kan udføre de nødvendige funktioner. Linkeren skal benyttes til
sammenkædning af objektmoduler til applikationsprogrammer, OS-moduler og
EOS-kernen. Den skal derfor minimum kunne danne loadmoduler med kode og
data i adskilte segmenter. De moduler, som skal sammenkædes betegnes
objektmoduler, og det sammenkædede modul kan enten være et sådant objektmodul,
som igen kan indgå i en sammenkædningsproces, eller et loadmodul, som kan
indlæses (enten som nytteprogram eller som OS-modul) og udføres.

                   <fig. 1. Systemdiagram.>

     Emnet for denne tekst er at specificere linkeren og derunder dens
grænseflader til oversættere og indlæseprogram (loader) respektive. I det
følgende afsnit redegøres for linkerens funktioner ved en gennemgang af
dens kommandosprog og logudskrifter. I afsnit 3 specificeres objektmodul-
formatet og i afsnit 4 loadmodul-formatet. Dernæst redegøres i afsnit 5 for
linkerens hovedalgoritme og vigtigste datastrukturer.


2. Funktioner.


     Hele ideen i EOS-systemer er jo, at sammenkædning (linkage) skal kunne
foregå dynamisk (i flugten). Den sammenkædning, der sigtes til i den
forbindelse, er sammenkædningen af hele EOS-objekter. EOS er imidlertid også
baseret på ideen om store objekter, hvis indmad fremstilles ved konventionel
programmeringsteknik - herunder separat oversættelse af delmoduler. Sammenkæd-
ningen af sådanne delmoduler til moduler, der kan udføres i EOS-objekter er
opaven for den her omtalte linker. Der er altså tale om sammenkædning EFTER
oversættelse og FØR indlæsning.
     Vi har valgt at tage udgangspunkt i objektkodeformatet, som benyttes i
UNIX-systemet på PDP-11. Dette giver mulighed for at opdele objektmodulerne
i 3 sektioner. Den første sektion rummer kode og de to sidste data. De to
første sektioner relokeres, medens den sidste er absolut. Da de to sidste
sektioner begge rummer data, placeres de i samme segment, og der skelnes
følgelig kun mellem dem, fordi sektion 2 skal kunne relokeres.

Desuden
kan der fremstilles en logudskrift, som redegører for de sammenkædede modulers
placering i de virtuelle adresserum ("memory-map").


Når linkeren aktiveres, skal følgende angives:

 1) Navne på objektmodulerne, som skal sammenkædes (i den rækkefølge, hvori
    de skal forekomme i det resulterende modul).
 2) Om et objektmodul skal dannes og i så fald hvilken fil, det skal skrives
    i, og evt hvilket navn, det skal have.
 3) Om et loadmodul skal dannes og evt. hvilket navn, det skal have og hvilken
    fil, det skal skrives i.
 4) Om en logudskrift skal dannes og evt. hvilken fil, den skal skrives i.

Eventuelt skal der tilbydes yderligere variationsmulighed. Den endelige
kommandosyntaks fastlægges først, når det er afgjort, hvordan programmet skal
aktiveres, og når der er taget stilling til en evt. fælles standard for
kommandoer til EOS-systemets programmer. (UNIX-style?):


LINK (options) (-O obj-file) (-E exe-file) (-M map-file) file...


3. Objektmodul-format.

     Objektmodulets format er fremkommet ved en krydsning af Unix's
og IBM's objektformat. Den væsentligste forskel i forhold til UNIX er,
at relokeringsinformationen er spaltet i to dele - eksterne symboler og
egentlig relokeringsinformation. Samtlige eksterne symboler anføres
eksplicit uanset om de eksporteres eller importeres, og relokerings-
informationen er komprimeret til en bit-map, som udpeger de oktetter i
objektkoden, som skal relokeres. Det fremgår af koden selv, hvilket segment
der skal relokeres i forhold til.  Den væsentligste forskel i forhold til
IBM er, at kataloget over eksterne symboler følger efter objektkodedelen,
hvor den i IBM-formatet går forud for denne. Formatet afviger fra begge
de nævnte ved at omfatte en del, der rummer information, som overgives
ubehandlet til loaderen, og ved ændret indhold i header-delen.
     I det følgende gives en specifikation af objektmodulformatet i en
(stærkt uformel) Pascal-lignende notation. De simplere typer specificeres
slet ikke i denne sammenhæng. F.eks. må læseren gætte sig til at
symbol_type = ARRAY(.1..max_symbol_length.) OF char.

TYPE

objectmodule_type =
RECORD
   header : header_type;       (* Generel information og indeks for resten *)
   loader : loader_type;       (* ubenhandlet information til loaderen *)
   image  : image_type;        (* object code *)
   esd    : esd_type;          (* external symbol directory *)
   rld    : rld_type;          (* relocation directory *)
   trailer: trailer_type       (* CRC checksum *)
END;

header_type =
RECORD
   format_code : integer;
   module_id : symbol_type;
   creation_date : date_type;
   option : integer;       (* magisk tal ?? *)
   entry : address;        (* loader section ?? *)
   unused_1,
   unused_2: integer;
   index : ARRAY(. objectmodulesections .) OF RECORD
      start,
      length : address;
     END;
END;

(* Der er ikke behov for flag til at angive, at relokeringsinfo mangler.
   Det fremgår af, at index(. pågældende sektion .).length = 0 *)

objectmodulesections = (loader, image, esd, rld, trailer);

loader_type = ARRAY(.1..header.index(.loader.).length.) OF byte;

image_type =  ARRAY(.1..header.index(.image.).length.) OF byte;

esd_type =
RECORD
   import_count,
   export_count: long_integer;
   import_table: ARRAY(.1.. import_count .) OF esd_entry_type;
   export_table: ARRAY(.1.. export_count .) OF esd_entry_type;
END;

esd_entry_type =
RECORD
   symbol_id: symbol_type;
   symbol_kind: symbol_kind_type;
   symbol_value: address;
END;

synbol_kind_type = (unresolved, absolute, relocatable, entry)

rld_type = ARRAY(.1.. (header.index(.image.).length - 1) DIV 8 + 1 .) OF bit;

trailer =
RECORD
END;«eof»
DataMuseum.dk

Bogika Butler

⟦a20178b3f⟧ TextFile

Derivation

TextFile
