International Conference on

Computer Systems and Education I ISc Bangalore

Typ esafe Comp osition of Ob ject Mo dules

Guruduth Banavar Gary Lindstrom Douglas Orr

Department of Computer Science University of Utah

Salt LakeCity Utah USA

Abstract Intro duction

It is widely agreed that strong typing in

We describ e a facility that enables routine

creases the reliability and eciency of soft

typ echecking during the linkage of exter

ware However compilers for statically typ ed

nal declarations and denitions of separately

languages suchasC and C in tradi

compiled programs in ANSI C The primary

tional nonintegrated programming environ

advantage of our serverstyle typ echecked

ments guarantee complete typ esafety only

linkage facility is the ability to program the

within a compilation unit but not across

comp osition of ob ject mo dules via a suite of

suchunits Longstanding and widely avail

strongly typ ed mo dule combination op era

able linkers comp ose separately compiled

tors Such programmability enables one to

units bymatching symb ols purely byname

easily incorp orate programmerdened data

equivalence with no regard to their typ es

format conversion stubs at linktime In ad

Such common denominator linkers accom

dition our linkage facility is able to automat

mo date ob ject mo dules from various source

ically generate safe co ercion stubs for com

languages by simply ignoring the static se

patible encapsulated data

mantics of the language Moreover com

monly used ob ject le formats are not de

signed to incorp orate source language typ e

information in an easily accessible manner

This researchwas sp onsored by the Advanced

In this pap er we presenta technique to

Research Pro jects Agency DOD monitored by the

p erform typ e checking of ob ject mo dules as

Department of the Navy Oce of the Chief of

a routine linktime activity Our technique is

Naval Research under Grantnumb er NJ

The views and conclusions contained in this

characterized by i the design of sp ecic lan

do cument are those of the authors and should not

guage typ e systems into a systemwide linker

be interpreted as representing ocial p olicies ei

ii programmed linktime control over indi

ther expressed or implied of the Advanced Research

vidual symb ols of ob ject mo dules and iii

Pro jects Agency or the US Government Contact

author G Banavar Computer Science MEB

University of Utah Salt LakeCity UT USA e C style namemangling do es not accomplish

mail banavarcsutahedu phone complete typ esafety across compilation units see

fax Section

utilization of standard debugging informa similar to Mo dula using memb er or

tion generated by compilers for typ e check der and typ e signicance along with names

ing We describ e in detail the realization of

Furthermore our programmable linkage

these steps for ANSI C

facility enables the incorp oration of auto

matic and userdened conversion routines

A crucial enabler for this facility is the abil

for encapsulated data For automatic con

ity to resolve inconsistencies among compiled

version we p ostulate safe adaptability rules

ob ject mo dules at link time The existence

for converting builtin data typ es using the

of link time typ e errors do es not mean that

language denition in conjunction with the

program source les need to b e mo died and

characteristics of particular hardware plat

recompiled as this may not b e p ossible for

forms We then utilize these rules to auto

precompiled libraries Programmer control

matically generate data conversion stubs

for correcting link time typ e errors is pro

at link time More imp ortantly program

vided via the already existing programming

mer dened conversion stubs can also b e eas

facilities of OMOS our dynamic linker

ily incorp orated at link time This op ens

For instance consider the case where the

up the p ossibility of programmercontrolled

typ e of a declaration in one translation unit

data evolution and conversion across hetero

do es not match with a denition in another

geneous data formats eg those arising from

This can usually b e xed by i uniformly re

dierent languages hardware architectures

naming the declaration and its uses to match

etc

the actually intended denition name or ii

Weprovide the abilitytosupportavari

in the case when the names match but the

etyoftyp e systems by designing our typ e

typ es do not byintro ducing a new decla

checking facility as an extension of an ob ject

ration to match the denition and binding

oriented framework The OO framework

the renamed original declaration with a typ e

contains generic typ e system related abstrac

conversion function Our linkage facility eas

tions suchas named typ es function typ es

ily supp orts such transformations If a typ e

record typ es etc that are sp ecialized via in

error cannot b e corrected with such simple

heritance to implement the typ e domain of

transformations on ob ject mo dules it might

sp ecic languages

indicate a more serious error in the design of

In the following sections we describ e in

the mo dules involved

detail the typ echecking of ob ject mo dules

generated by compiling ANSI C programs

Our linktime typ echecking facility p er

Section intro duces our notion of mo dules

mits us to adapt and utilize the full expres

and interfaces Section briey describ es our

sivepower of language typ e systems to b et

ob ject server OMOS and Section discusses

ter suit mo dern p ersistent distributed and

the essential asp ects of the typ e system of

heterogeneous environments For example

ANSI C We then give some implementation

structural typing can b e applied to languages

details discuss related work and conclude

such as ANSI C with namebased typing

Pure namebased typing b ecomes a problem

in p ersistent and distributed environments

Ob ject Mo dules and

where data and typ es could migrate out

side the program in which they were orig

their Interfaces

inally created and lead to matching of

names that mayormay not have the same We refer to an ANSI C program source or

programmerintended meaning This argues ob ject le as a module consisting of a set

for structural matching of aggregate typ es of attributes with no order signicance An

the compiled mo dule O provides a deni attribute is either a lelevel declaration a

tion of function f Consider the case where name with an asso ciated typ e eg extern

a programmer creates and compiles mo dule int i or a lelevel denition a name

O with the intention of using Os f deni with a data storage or function binding

tion by p erforming O merge O but makes Typ e denitions eg struct denitions

the incorrect presumption that f returns an and typedefs in C are not attributes of

intIfmerge were untyp ed as it is in com a mo dule The interface of a mo dule con

mon linkage O merge O would have b een sists of name typ e declared or dened

legal howeveritdoesnottyp echeck in our tuples of the attributes of the mo dule In the

linker since the interfaces of O and O are context of typ echecking ob ject mo dule inter

not typ e compatible for a merge op eration faces attributes match if they have the same

Let us say that the programmer of O dis name There cannot b e matching attributes

y

coversduringlinkage that f returns the de within a single interface and attributes that

sired int value as a comp onent of the re match across interfaces must b e typ e com

turned structure Traditionally in order to patible The notion of typ e compatibilityde

make O and O compatible the program p ends on the particular mo dule combination

mer would mo dify the source co de of either op eration b eing p erformed and is informally

mo dule extensivelyifitwere available and describ ed b elow

recompile This of course could adversely

Our linker is based up on a formal mo del

aect combination of the mo died mo dule

of mo dules prop osed in achieving a ne

with yet other mo dules Alternatively in our

level of control over individual attributes of

mo del of exible linktime mo dule adapta

ob ject mo dules Briey ob ject mo dules are

tion O can b e adapted to get the desired ef

combined via a suite of mo dule combination

fect by constructing a stub mo dule O O

operators that were originally conceived to

consists of a new declaration that matches

describ e the many facets of inheritance in

fs denition and a stub function that ex

ob jectoriented programming Figure gives

tracts the desired value from the structure

the primary op erators their informal seman

returned by f With this a mo died ver

tics and typ e rules These op erators pro

sion of O is obtained with the mo dule ex

vide control over asp ects of visibility sharing

pression O rename f f stub merge O

and rebindability of individual attributes of

which can then b e mergeed with O to get

mo dules The p ower that this mo del lends

the originally desired eect

to ob ject mo dule linkage is briey given in

Section and is describ ed in more detail

in where the original implementation of

The OMOS Linker

the typ eless OMOS linker is describ ed The

current eort incorp orates the rules of the

In this section we describ e our linkage

strongly typ ed mo dule mo del and illustrates

facility the Ob ject MetaOb ject Server

some of its applications

OMOS

The semantics of common linkageisem

The OMOS linkerloader is designed to

b o died in the mo dule op erator merge For

provide a dynamic linking and loading facil

a simple example of the use of this mo dule

ity for client programs via the use of mo dule

op erator consider Figure In this gure

combination and instantiation OMOS im

plements a p ersistent hierarchical namespace

y

In order to mo del languages that supp ort user

muchlike the UNIX directory hierarchy

dened overloading eg C our mo del can b e ex

whose leaf no des are either ob ject mo d

tended to include an ordinal value in the tuple which

is also signicant for attribute matching ules o les or metaobjects Metaob jects

Op erator Semantics Typing

M merge M Combine M and M Matching denitions disallowed a denition must

be a subtyp e of its matching declaration

M override M Merge but resolve matches in Same as merge except rightop erand denition

favor of right op erand must b e a subtyp e of matching left opnd denition

M restrict L Make L undened L must b e dened

M freeze L Make references to L static L must b e dened

M hide L Make attribute L private L must b e dened

M rename L L Rename L its uses to L L must exist L must not

M copyas L L Copy attribute named L to L L must b e dened L must not exist

Figure Informal Semantics and Typing of Mo dule Op erators

Module O Module O Module O

struct S f struct S f

int x extern int f int x

g void bar f g

int x foo extern struct S f

struct S f f g int f stub f

return fx

g g

Mo dules O and O are comp osed with the expression O rename f f stub merge O merge O

Figure Linkage Adaptation

are named placeholders for mo dules that are given mo dule eg library vs ordinary mo d

sp ecied by mo dule combination expressions ule among others The op erands in

OMOS essentially provides a level of indirec mo dule expressions may b e executable co de

tion b etween a named OMOS entityamod or data fragments other mo dule expressions

ule and its actual implementation a mo dule or other named metaob jects

instance that is loaded into a client Clients

Since OMOS is an activeentity a server

may directly load named mo dule implemen

it is capable of p erforming sophisticated

tations or generate new mo dules by combin mo dule manipulations on each instantiation

ing or mo difying existing ones This facility of a mo dule Evaluation of a mo dule ex

is used as the basis for system program ex

pression could p otentially pro duce dierent

ecution and shared libraries as well as

results eachtime Some OMOS op erations

dynamic loading of simple mo dules

such as those used to implement program

monitoring and reordering enact pro

Expressions sp ecifying mo dule combina

gram transformations using op erations on

tion are enco ded in a scripting language with

a LISPlikesyntax These expressions con mo dule expressions

sist primarily of op erations for manipulat For example monitoring a program using

ing mo dules and mo dule namespaces such OMOS mightinvolve extracting and trans

as those shown in Figure Additionally forming the expression that generates the

OMOS supp orts op erations for constructing program so that each dened pro cedure is

an ob ject mo dule given program source co de transparently wrapped with an outer routine

and for sp ecializing the implementation of a that monitors entry to and exit from the pro

cedure Figure shows the mo dule op era for typ echecking across compilation units

tions used to wrap the pro cedure f in mo d structural typing and subsumption

ule O with the automatically generated rou

The typ e domain of ANSI C consists

tine found in O Note that this illustrates

of i basic typ es primitivetyp es int

adaptation of the service provider mo dule

float etc and enumerated typ es ii

while Figure showed client mo dule adapta

derived typ es function typ es struct and

tion

union typ es array and p ointer typ es and

iii typedefed names Sp eciers for these

This pro cess of wrapping pro cedures is en

typ es can b e augmented with typ e qual

hanced bytheavailability of mo dule typ e in

iers const and volatileand storage

formation The wrapp er pro cedure is con

class sp eciers auto register static

structed with a signature identical to that of

and extern

the wrapp ed pro cedure simple language con

structs can b e used to propagate the callers

The typ e qualier volatile concerns opti

arguments to the wrapp ed routine If typ e

mization and is not relevant here The qual

information was not available or in cases

ier const is explicitly dealt with in this sec

suchasprintf where the the routine is de

tion The storage class sp eciers auto and

ned to takea variable numb er of arguments

register are not relevant since they may

it would b e necessary to use a machine

only b e used within functions we are in

dep endent wrapp er that could preserveand

terested in lelevel declarations and deni

pass along the call frame without knowledge

tions The storage sp ecier extern indicates

of its contents

an attribute declaration while nonextern at

tributes are considered to b e dened The

While OMOS is capable of p erforming so

storage sp ecier static for a lelevel at

phisticated manipulations on eachinvoca

tribute gives it internal linkage ie the at

tion it caches the results of most op erations

tribute can b e viewed as having b een sub

to avoid redoing work unnecessarily The

jected to a hide mo dule op eration Simi

practice of combining a caching linker with

larly attributes that are sub jected to hide

the system ob ject loader gives OMOS the

via linktime programming can b e regarded

exibilitytochange implementations as it

as having b een converted to the static stor

deems necessary eg to reect an up dated

age class after the fact

implementation of a shared mo dule across all

its clients C p ermits calls to functions that have not

b een declared in a mo dule A call to an un

declared function f in a mo dule results in an

implicit lelevel declaration of extern int

Cs Typ e System

f

This concludes the general discussion of link

age via mo dule manipulation

Typ e Equivalence

In order to ascertain the typ esafetyof

mo dules b eing combined the mo dule typ e

Typ e equivalence in ANSI C within a

rules shown informally in Figure built

single translation unit and our extensions

into our linker requires knowledge of the typ e

for typ echecking across translation units is

system typ e domain typ e equivalence and

given in Figure The rationale for the two

subtyping of the base language ANSI C

mo dications are

This section describ es the relevanttyp e sys

tem of ANSI C typ e domain and typ e equiv For aggregate typ es structs and

alence and enhancements made to it unions name equivalence is to o weak

Module O Module O

Automatically generated

f short extern short

extern void log enter char

log exit char extern void

void g f short f short x f

short z f short v

log enter f g

v fx

log exit f short f short x f

return v

g g

Mo dule expression O copyas f f restrict f merge O hide f

Figure Wrapping a routine to monitor its execution

Typ e Equivalence within a translation unit Equivalence across translation units

Primitivetyp e name equivalence same

Function typ e structural with in and out parameter same

typ es signicant

Enum typ e name equivalence same

Structure and name tag equivalence tagless typ es structural with tag memb er order

union typ e are unique and memb er names signicant

Pointer typ e equivalence of target typ es same

Arraytyp e equivalence of elementtyp es and eq same

ualityofarray size

typedefed name typedefed typ e typedef name equivalence

Figure Typ e equivalence in ANSI C

The typ e qualier const is signicantfor when applied outside of a single transla

equivalence since it distinguishes readonly tion unit as explained in the intro duc

variables from readwrite variables tion Therefore we adopt a conserva

tive structural typing regimen in which

the names order and typ es of mem

Subtyping

b ers are also signicant We also re

The mo dule op erators merge and override

tain the signicance of aggregate tags

utilize subtyping rules for typ echecking com

since there could b e applicationsp ecic

bination Our base language ANSI C has

semantic content in them

no notion of subtyp es hence subtyping can

For typedefed names again there

b e considered to b e restricted to typ e equiv

could b e applicationsp ecic semantic

alence However mo dule comp osition would

content in them so we adopt strict name

b e more exible if we could retroactively for

equivalence

mulate subtyping rules consistent with the

Furthermore some typ e sp eciers are im language denition

plied by others eg short implies short The ANSI C language sp ecies safe con

int therefore these typ es are equivalent version rules for certain primitive arithmetic void

long double double

long int long unsigned int int float unsigned int

short int short unsigned int bit-field enum X signed char unsigned char 1 < sizeof (short) < sizeof (int) == sizeof(long) == sizeof(float)

sizeof (float) < sizeof (double) == sizeof(long double)

Figure Subtyping of C PrimitiveDataTyp es

data typ es eg float to double Acon inal while expressions which are acceptors

version is said to b e safe if all values of can only b e replaced by expressions whose

one typ e can b e represented as values of the typ es are sup ertyp es of the original As

the other without loss of precision or change a result subtyping of variables is always re

in numerical value C compilers however stricted to typ e equivalence

can usually b e exp ected to supp ort many

Consider lelevel readonly ie const

more safe conversions than those that are de variables Subtyping involving the typ e qual

ned by the language as governed by hard ier const can b e describ ed as follows if a

ware characteristics These safe conversion nonconst typ e s is a subtyp e of a nonconst

rules can b e thoughtofassubsumption rules typ e t then const s is a subtyp e of const

which in turn provide the basis for formu

t s is a subtyp e of const tbutconst s

lating subtyp e rules for primitive arithmetic is not asubtyp e of t So for example can

typ es Figure shows the data typ e sizes and a declaration extern const float x in one

a partial order of subtyp es for the HP series translation unit b e considered subsumed by

machines s and s For instance a denition short x in another

avalue of typ e short can b e safely co erced

Unfortunately this is not the case since

into a value of typ e float on this platform size and layout formats for various primitive

without loss of precision or change in numer data typ es are almost certainly incompatible

ical value We might ask if the ab overules Moreover in certain cases eg enum typ es

can b e exploited during typ echecking of at

compilers usually optimize layout bypack

tributes across translation units

ing hence the fact that an enum typeisreally

Consider lelevel variable declarations an int cannot b e utilized Within the same

translation unit however such subsumption

Variables can b e used as evaluators ie ex

rules can b e applied since the compiler has

pressions that return values and as accep

tors ie expressions that receivevalues in complete knowledge of layout and usage and

dierent contexts Expressions whichare hence it can generate appropriate conversion

evaluators can only b e replaced with expres and access co de

sions whose typ es are subtyp es of the orig Similar arguments hold for subtyping

constant userdened aggregate data typ es for direct application in typ echecking across

struct and union across translation units translation units

For example a struct of two shortscan

The crucial observation however is that

not b e considered to b e a subtyp e of a const

several useful subsumption rules can b e uti

struct of two const floatseven though

lized for data that are encapsulated within

short is a subtyp e of const floatFurther

functions if stubs that p erform the appro

more C unions are not discriminated and

priate co ercion b etween datatyp es can b e

memb er access is not typ echecked at run

inserted b etween combined mo dules at link

time For example a union with one short

time This is feasible since such stub func

comp onent cannot b e readonly accessed by

tions are themselves compiled and hence they

a sup ertyp e a union with a const short

can utilize data format conversion knowl

and a const float comp onent in another

edge that a compiler uses within a transla

translation unit since there is no way for the

tion unit Applying this stub technique to

sup ertyp e accessor to know at runtime if the

global datahowever is not feasible since

union actually contains a short value or a

it involves initializing global variables with

float value As a result subtyping on le

nonconstantvalues which is illegal in ANSI

level readonly variables is also restricted to

C

typ e equivalence

Function typ es lend themselves particu

larly well to this technique since the p er

Arguments such as the ab ove can b e for

formance of function calls is aected much

mulated to show that subtyping on p ointer

less by this indirection than the p erformance

typ es is also restricted to typ e equivalence

of data access Moreover it do es not seem

Consider subtyping of function typ es

unreasonable to imp ose the requirementon

Subtyping of function typ es is by contravari

users to encapsulate such data that they fore

ance That is a function typ e is a subtyp e

see will b e accessed via sup ertyp es

of another with the same numb er of argu

Our linker automatically generates co er

ments if its return typ e is a subtypeofthe

cion stubs for functions using the primitive

latters and its input argumenttyp es are su

typ e conversions shown in Figure For an

pertypes of the corresp onding ones in the lat

example of typ e adaptation using language

ter According to this rule one can pass a

dened subtyp es consider Figure As men

function actual parameters that are subtypes

tioned earlier the typ e short is a subtyp e of

of the formal parameters in the function de

float Therefore the denition of function

nition For subtyping function typ es with an

f in mo dule O isasubtyp e bycontravari

unsp ecied variable numb er of arguments

ance of the declaration of the function f in

we require that the subtyp e has at most the

mo dule OHowever O cannot b e directly

numb er of explicitly sp ecied argumenttyp es

merged with O since in general the calling

in the sup ertyp e and that they are in the

sequence for f might not b e compatible eg

prop er relationship

the denition of f might b e exp ecting its in

put in a oating p oint register rather than

However we cannot use such a rule across

an integer register This is remedied byrst

translation units since in a compiled func

combining O with the automatically gener

tion the amount of space allo cated for the

ated stub mo dule O that incorp orates safe

input parameters is exactly the size of the

co ercions and then p erforming the desired

exp ected typ es and the format is exp ected

merge as shown in the gure

to b e exactly as sp ecied All in all and

Wehave also incorp orated a comprehen not surprisingly no useful subtyping rules

sivesubtyping mo del including structural can b e discovered in the existing C language

Module O Module O Module O

Automatically generated

short f float y f extern float f short extern short f float

stub short x f g void g f float f

float z f return float f float x

g g

Mo dules O and O are combined with the expression

O rename f f stub merge O hide f stub merge O

Figure Automatic Data Co ercion Using Language Rules

record subtyping with memb er name typ e instructs the compiler to generate typ e infor

and order signicance an example of which mation in a standard enco ded format

is shown in Figure It should b e empha

Although conceptually simple the actual

sized that the ab ove technique applies only

pro cess of extracting typ e information from

to input and output parameters of functions

the generated debugging information is tech

since co ercion stubs can b e automatically

nically challenging and in our prototyp e in

generated to account for function subtyping

volved the following steps The GNU C com

only

piler gcc do es not generate debugging in

This technique of typ e conversion stubs

formation for C extern symb ols since de

can b e generalized as illustrated in Figure

bugging is normally p erformed on executable

to provide a general facility to incorp orate

les in which all external references have

user dened stubs at link time for arbitrary

b een resolved To solvethiswe mo died the

data format conversion In the gure mo d

backendof gcc to generate debugging infor

ule O comprises userdened stubs

mation for all symbols For accessing the sec

tions of the ob ject le that contain debugging

information stab and stabstr we use

Implementation And

Cygnus Corp orations Binary File Descrip

Usage Details

tor BFD library and parse the stabs

format debug strings using a yacclex

Ideallywewould have compilers that gener

generated parser

ate ob ject mo dules in a selfdescribing for

mat with information ab out the source lan

We are implementing an OO framework

guage the machine architecture and the in

in C that emb o dies the formal mo dule

terface all packaged within the ob ject mo d

mo del that was briey describ ed in Section

ule in a readily accessible format However

The abstractions classes in the frame

this is far from reality the closest approx

work implementthetyp e rules discussed in

imation is an ob ject le that has b een com

the previous section For instance the frame

z

piled with the debugging option g which

work class CPrimType implements the partial

order of primitivetyp es intro duced b efore

z

Ob ject les compiled without the debugging op

A framework class called Interface imple

tion contain no typ e information and those compiled

ments the typ e rules for mo dule op erations

with the debugging option contain more information

suchas merge The parser mentioned in the

than is necessary for typ echecking linkage eg typ es

of lo cal variables line numb ers etc previous paragraph instantiates the appro

Module O Module O Module O

Automatically generated

struct S f struct S f struct S f

short x float x short x

float y g float y

g g

extern struct S f struct S f

struct S f f float x

void g f g

g extern struct S f

stub f g struct S f

struct S s

struct S s struct S s

struct S ret s

s f

ret sx float sx

return ret s

g

Mo dules O and O are combined with the expression

O rename f f stub merge O hide f stub merge O

Figure Automatic Conversion of structs Using Structural Subtyping

Module O Module O Module O

R f T y f extern R f T extern R f T

stub T x f g void g f R f

to R f T to Tx R z f T value return R

g g

R R to R R r f

g

T T to T T t f

g

Mo dules O and O are combined with the expression O rename f f stub merge O merge O

Figure Programmerdened Data Conversion

priate classes in our OO framework to create ual page explains the inadequacy

the interface of the ob ject mo dule of header les as follows

For using our typ echecked linkage facil

C tried to ensure the consis

ity the source programs currently must b e

tency of separately compiled programs

written in ANSI C and function declarations

bycontrolling the information given

sp ecied using newstyle prototyp es Fur

to the compiler in header les This

thermore usage of header les can b e mini

approachworks ne up to a p oint

mized explicit declarations of external func

but do es involve extralinguistic mech

tions can b e provided instead Programs

anisms is usually errorprone and can

that are to b e typ echecked at link time must

b e costly b ecause of the need to have

b e recompiled with our mo died compiler

other programs in addition to the

using the debug g option

linker and the compiler know ab out

One legitimate concern is the size of ob ject

the detailed structure of a program

les as a result of the inclusion of debugging

information The size of ob ject les do es in

Instead of including header les it is clearly

crease signicantly due to debugging infor

more mo dular and less errorprone to explic

mation but this problem is exacerbated by

itly declare the exp ected external function

the inclusion of huge library header les Our

alityeg library functions let the linker

solution to this problem is that given typ e

check consistency at link time and correct

checking at linktime it is not necessary to

inconsistencies via programming

include header les in the traditional way

With the ob jective of enabling typ esafe

Instead programs can explicitly declare pro

linkage within the constraints of existing

totyp es for those external library functions

linkers Stroustrup describ es a mech

that are called A discussion of the disadvan

anism for enco ding functions with the typ es

tages of header les used in the traditional

of input arguments However this mecha

manner is found b elowinSection

nism is inadequate for our purp oses since i

certain classes of typ e errors cannot b e de

tected page of since variable typ es

Related Work

and function return typ es are not enco ded

ii although it could b e extended to deal

Integrated Development Environments

with structural typing of C aggregate typ es

IDEs for strongly typ ed languages eg

it do es not scale well to arbitrarily large

Eiel undoubtedly utilize mechanisms

typ es eg large structs and iii wewant

for typ echecking separately compiled mo d

to do not only typ echecking but also useful

ules since they have complete knowledge

adaptation during linktime hence wemust

and control over source and ob ject mo dules

utilize sophisticated linker technology

However our work diers from IDEs in that

we provide a systemwide linkage facilitythat The Berkeley Pascal Compiler pc is

attempts to typ echeck combined mo dules in similar to our eort in that it employs

dep endent of language pro cessors Further debugging information to checktyp e con

more the programmability of our linker en sistency across separately compiled mo d

ables ne tuning the compatibility of p os ules The compiler routinely generates stab

sibly heterogeneous ob ject mo dules at link format typ e information into ob ject mo dules

time whichisusedby a binding phase of the com

Use of header les has b een a longstanding piler to check consistency b efore delegating

attempt at typ esafety of separate compila the actual linking to ldHowever the crucial

tion The Annotated C Reference Man advantage with our approachisthatwe p er

form typ echecking as a controlled and pro Linktime typ e checking of mo dule combi

grammable linktime activity nation also op ens up the p ossibilityofmore

There is a plethora of literature related expressivetyp e systems The current status

to stub generation The Poly of static typ e systems for OO languages is

gen system is representativeof auto unable to deal with for example p olymor

matic stub generation for programming in a phic inheritance op erators which has several

heterogeneous environment Polygen pack software engineering applications

ages heterogeneous mo dules by utilizing a

We are currently in the pro cess of extend

programmerdened sp ecication of their in

ing OMOS to include a small LISP inter

terfaces and execution environments sp eci

preter to replace the sp ecialpurp ose mo dule

ed in a common mo dule language The

expression language This change will allow

packaging pro cess involves generation of

conditional pro cessing of mo dules denition

client and server stubs that handle mo dule

of functions etc In addition we are pro duc

interconnection and data typ e co ercion dy

ing an interface to OMOS that will allowit

namically Our technique diers from Poly

to subsume the role of the system linker

gen in that we enable the combination of pre

compiled ob ject mo dules by automatic ex

traction of interfaces and via linktime pro

Conclusion

gramming

Wehave describ ed a programmable linkage

Ongoing Work

facility for separately compiled ANSI C ob

ject mo dules The programming mo del of

We are currently completing our implemen

our linker is based on a formal notion of

tation and lo ok forward to get more exp eri

mo dules and their comp osition via a suite

ence in using suchatyp esafe linkage facility

of strongly typ ed op erators We design the

Weacknowledge the shift in the traditional

typ e system of ANSI C into our linker and

cycle of programming that may b e required

typ echeck comp osition by extracting the in

as a result of using a programmable typ e

terfaces of ob ject mo dules compiled with de

checking linker Also automatically gener

bugging information Furthermore we auto

ating stub functions for all varieties of typ e

matically generate conversion stubs for com

compatible functions is considerably hard

patible encapsulated typ es and p ermit easy

For example generating sensible stubs for

incorp oration of arbitrary userdened typ e

function calls involving reference parameters

conversion stubs at link time Wehavethus

ie p ointer parameters in C is somewhat

demonstrated a p owerful exible and typ e

more dicult and is currently b eing worked

safe linkage facility

on

We foresee several applications for our

Acknowledgments

typ esafe linkage facility In the immediate

future we plan to extend this technique to Wearevery thankful to Rob ert Mecklenburg

apply to OO languages such as C whose and Jay Lepreau for numerous useful comments

typ e systems are signicantly more complex and to Pete Ho ogenb o om and Jerey Law for

than the simple typ e system of C Further sharing their knowledge of the inner workings

more if typ e equivalence and subtyping rules of current compilers and linkers The insights

can b e established across programming lan and supp ort of Tim Mo ore Benny Yih and all

guages our facility enables multilingual pro other Mach Shared Ob jects pro ject participants

gramming are also gratefully acknowledged

References Margaret A Ellis and Bjarne Stroustrup

The Annotated C Reference Manual

Rob erto M Amadio and Luca Cardelli

AddisonWesley Reading MA

Subtyping recursivetyp es ACM Transac

Brian W Kernighan and Dennis M

tions on Programming Languages and Sys

Ritchie The C Programming Language

tems Septemb er

PrenticeHall Englewo o d Clis NJ

Guruduth Banavar and Gary Lindstrom

B Lyon Sun remote pro cedure call sp ec

A framework for mo dulebased language

ication Technical rep ort SUN Microsys

pro cessors Computer Science Department

tems

Technical Rep ort UUCS University

Julia Menapace Jim Kingdon and David

of Utah March

MacKenzie The stabs debug format

BN Bershad TE Anderson ED La

Free Software Foundation Inc Contributed

zowska and HM Levy Lightweightre

by Cygnus Supp ort

mote pro cedure call Association for Com

Bertrand Meyer Eiel the environment

puting Machinery Transactions on Com

August

puter Systems February

Ed Greg Nelson Systems Programming

AD Birrell and BJ Nelson Implement

with Modula Prentice Hall Englewood

ing remote pro cedure calls Association

Clis NJ

for Computing Machinery Transactions on

Douglas Orr John Bonn Jay Lepreau

Computer Systems February

and Rob ert Mecklenburg Fast and exible

shared libraries In Proc USENIX Sum

Gilad Bracha The Programming Language

mer Conference pages Cincin

Jigsaw Mixins Modularity and Multiple

nati June

Inheritance PhD thesis Universityof

Douglas B Orr and Rob ert W Mecklen

Utah March Technical rep ort UUCS

burg OMOS An ob ject server for pro

pp

gram execution In Proc International

Workshop on Object OrientedOperating

Kim B Bruce A paradigmatic ob ject

Systems pages Paris September

oriented programming language Design

IEEE Computer So cietyAlsoavail

static typing and semantics Technical Re

able as technical rep ort UUCS

p ort CS Williams College January

Douglas B Orr Rob ert W Mecklenburg

Peter J Ho ogenb o om and Jay Lepreau

John R Callahan and James M Purtilo A

Dynamic program monitoring and trans

packaging system for heterogeneous execu

formation using the OMOS ob ject server

tion environments IEEE Transactions on

In Proceedings of the th Hawaii Inter

Software Engineering June

national Conference on System Sciences

pages January Also avail

able as technical rep ort UUCS

Steve Chamb erlain libbfd Free Software

Foundation Inc Contributed byCygnus

Bjarne Stroustrup Typ esafe linkage for

Supp ort March

C In USENIX C Conference

Berkeley Software Distribution UNIX Satish R Thatte Automated synthesis of

Programmers Supplementary Documents interface adapters for reusable classes In

University of California Berkeley Califor Symposium on Principles of Programming

nia April LanguagesJanuary