by
Christine L. Tsien
S.B. Computer Scienceand Engi neeri ng, MassachusettsInsti tuteof Technology
(1991)
Submi ttedtotheDepartmentof El ectri cal Engi neeri ngandComputerSci ence
i nparti al ful l l mentof therequi rementsforthedegreeof
Masterof Sci encei nEl ectri cal Engi neeri ngandComputerSci ence
atthe
MASSACHUSETTSINSTITUTEOF TECHNOLOGY
May1993
c
Chri sti neL. Tsi en,MCMXCIII.
TheauthorherebygrantstoMITpermi ssi ontoreproduceand
by
Chri sti neL. Tsi en
Submittedto theDepartmentof Electrical EngineeringandComputer Science
onMay7,1993, inpartial fulllmentof the
requirements forthedegreeof
Masterof ScienceinElectrical EngineeringandComputerScience
Abstract
Withthe development of high-level languages for new computer architectures comes the
needforappropriatedebuggingtools aswell. One methodfor meetingthis needwouldbe
todevelop, fromscratch, asymbolicdebugger withtheintroductionof eachnew language
implementationfor anygivenarchitecture. This, however, seems torequire unnecessary
duplicationof eort amongdevelopers. Compilationtechnologyhas alleviatedsome du-
plicationof eort inthe development of compilers. Cansimilar ideas aidinthe ecient
developmentof symbolicdebuggers aswell?
Maygenexploresthepossibilityof makingdebuggerdevelopmentecientbyinuencing
the language andarchitecturedevelopment processes. Maygenis a\debugger generation
system,"builtupontheideathatsymbolicdebuggerscanbedividedintothreecomponents:
aset of sourcelanguageinterfaceroutines, asetof machinearchitectureinterfaceroutines,
andalanguage-independent andarchitecture-independentdebuggerskeleton. Maygenthen
exploits this modularity: First, Maygenpreciselydenes as well as houses the language-
independent andarchitecture-independent debugger skeleton. Second, Maygendenes the
protocol for interfaceinteractionamongsource language developers, machine architecture
developers, andthe general-purposedebugger skeleton. Finally, Maygenprovidesaframe-
workinwhichtheresidentdebugger skeletonisautomaticallydevelopedintoastand-alone
symbolicdebugger;theresultingdebuggeristailoredtothespecicprovisionsof aparticular
languagegroupandaparticulararchitecturegroup.
Thesis Supervisor: ThomasF. Knight, Jr., Ph.D.
Title: Principal ResearchScientist, Department of Electrical EngineeringandComputer
Science
Thesis Supervisor: AlanL. Davis, Ph.D.
Title: CompanySupervisor, Hewlett PackardLaboratories
Ackno wl edgments
First, IwouldliketothankAl Davisforbeingagreatleaderandadvisor, forunderstanding
that withhighmoraleandinterestingworknaturallyfollows true motivationandquality
performance. (I.e., occasional goof-odays, suchas groupoutings tosee Terminator 2or
watchthe Giants, keeps people happyanddiligent throughsubsequent crunchtimes.) I
wouldalsoliketothankhimfor his careful readingof mythesis draft. I wishhimall the
bestwithMayyaswell as his futureendeavors.
I wouldlike tothankTomKnight for agreeingtobe myMITsupervisor, for being
positiveandsupportiveof myworkeventhoughthescopeorfocus seemedtochangenearly
everytimeIewtoMITforameeting, andforbeinginterestedineverything, thusmaking
himagreatresourceforadiverseset of questions.
I wouldliketothankMikeLemonfor his unwaveringsupport andfriendshipsincemy
rst HPsummer in1989. Morerecently, I amindebtedtohimfor lettingmeclutter half
of his diskspacewithmybackups, for his eloquentexpositionof abstract machinesduring
oneof myperiods of confusion, andfor subsequentlylettingmeborrowheavilyfromthat
descriptionfor myintroductoryparagraphsof Section4.2.
I wouldliketothankRobinHodgsonfor helpingtoeshout thepreliminarydebugger
generationidea, forhelpingmetounderstandtheMayy,andforhavingdonealotof work
onMaydebug, the guts of whichwent intomuchof myMayytest case. I alsowant to
thanktheMayygroupoverall for providingaveryenjoyableworkenvironment.
Next, thanks gotoJohnConeryforexplainingtheOPALsystemandforhavingdonea
lotof OPAL/OMwork, thegutsof whichwentintomuchof myOPALandOMtestcases.
I wouldliketothankBill Dallyfor beingsupportiveof mymedical interestsandespe-
ciallyfor signingmyregistrationevenwhenhethoughtI was takingtoomanyclasses.
Iwouldliketothankall of theMEDGmembersforbeingmyfostergroupatMITwhile
IwasnishingMaygenworkandforlisteningtomythesistalk; thetalkformatcontributed
Of courseI alsowanttothankall of myfriends|not onlythoseat MIT, whogaveme
muchneededandrelaxingbreaks fromwork, but alsothose whohave left MITbut still
remainclosetomeinspirit andinemail.
Special thanksgotoJamie: inall of mybusiesttimes, healonewasstillabletoconvince
metotakethreetovemini-breaksaday. (Itwaseitherthat, orspendtwiceas muchtime
cleaningupdoggyaccidents!)
I feel compelledtothankthe Associationof AmericanMedical Colleges for scheduling
theMCATstobethreeweeksbeforethethesisdeadline; hadtheMCATsbeenatadierent
time, I might nothavehadas goodanexcusefor not studyingas muchas oneshould.
As always, I amverythankful tomyparentsandmysister for theircontinual support,
guidance, patience, interest, andenthusiasminall of myendeavors.
I wholeheartedlythankGodfor helpingmewithall that I do, as well as for allowing
mybiggestproblemtobehavingtoomanychoices (alongwithaair for indecisiveness).
Last, but denitelynot least, I wouldlike to thankBrad Spiers for all of his love,
friendship, laughter, support, andencouragement. Ithankhimfornotliftinganeyebrowat
mycuttingcouponsandreadinggrocerystoreadsinthemidstof MCATstudiesandthesis
work. I thankhimforcorrectingmyalmost-clichesandcolloquialisms; if itweren'tforhim,
I'dbe ushingout ideasandsaying, \Close, but nobanana."Finally, I wanttothankhim
forlettingmesignhimupfor ColumbiaHouseVideoClubmembership(andthusgetting
thosetengreat newmoviesfor alowprice!) justwhenwemostneededtowork. :]
This paper describes researchconductedat Hewlett PackardLaboratories, as part of
the MITVI-AInternshipProgram, and at the Articial Intelligence Laboratoryof the
MassachusettsInstituteof Technology. Supportfor this researchwasprovidedinpartbya
National Science FoundationGraduateResearchFellowship. Support for thelaboratory's
articial intelligenceresearchisprovidedinpartbytheAdvancedResearchProjectsAgency
About the Author
ChristineTsienwas bornonthe28thof November, 1969, inMinneapolis, Minnesota. She
was educatedinpublic schools, graduatingvaledictorianfromMounds ViewHighSchool
inArdenHills, Minnesota, in1987. Withthenancial aidof aNational MeritScholarship,
she was able toattendthe Massachusetts Institute of Technology, where she majoredin
computerscience, concentratedinRussianlanguage, andmaintainedaninterestinbiology
andmedicine. As asophomore, she was invitedtoparticipate inthe VI-Aprogramwith
HewlettPackardLaboratoriesinPaloAlto, California. Shewaselectedtoandisamember
of TauBetaPi, EtaKappaNu, andSigmaXi, andsheservedas VicePresidentandSocial
Chair for EtaKappa Nuduring the 1990-91academic year. She has beena member of
the Societyof WomenEngineers for sixyears, duringwhichshe servedonthe Executive
CommitteeandtheFinancial Committeefor oneyeareachandas Treasurerfor twoyears.
She is alsoa member of the Associationfor ComputingMachineryandthe Biomedical
EngineeringSociety. She earnedher Bachelor of Science degree fromthe Department of
Electrical Engineering andComputer Science inJune, 1991. The author was accepted
intothedoctoral programat theMassachusettsInstituteof Technology, wheresherecently
nished her Master of Science degree with the nancial support of a National Science
FoundationGraduateFellowship.
Duringher years at the Massachusetts Instituteof Technology, theauthor alsopartic-
ipatedinAlphaPhi OmegaNational Service Fraternity, FigureSkatingClub, Freshman
AssociateAdvising, TechSquareBigSisters, ChineseStudents'Club, andProjectContact.
She was alaboratoryteachingassistant inthe BiologyDepartment, engagedinresearch
at the Laboratoryfor Computer Science andat theArticial IntelligenceLaboratory, and
workedvariousjobsinWestCampusHouses, ARAFoodService, andHaydenLibrary. She
alsovolunteeredat MountAuburn, BostonCity, andMassachusettsGeneral Hospitals. In
her spare time, she enjoys rollerblading, windsurng, watchinggoodmovies, andplaying
withher AmericanEskimodog, Jamie.
Her present researchinterests lieat the intersectionof computer science, biology, and
medicine. Her longer termgoals are to explore interdisciplinaryapproaches to solving
1 Intro duction 12
1.1 Project Overview: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 13
1.2 Thesis Organization : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 15
2 RelatedWork 18
2.1 Multilingual Debugging : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18
2.2 Language-independentDebugging: : : : : : : : : : : : : : : : : : : : : : : : 19
2.3 Advantages andDisadvantages : : : : : : : : : : : : : : : : : : : : : : : : : 19
3 Canonical GeneratedDebugger 21
3.1 Overview : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 21
3.2 Design : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 24
3.2.1 DebuggingUnoptimizedCompiledCode : : : : : : : : : : : : : : : : 24
3.2.2 ProvidingTailored, Traditional Functionality : : : : : : : : : : : : : 25
3.2.3 SupportingExtensionCommands: : : : : : : : : : : : : : : : : : : : 26
3.2.4 SupportingMultiprocessors : : : : : : : : : : : : : : : : : : : : : : : 26
3.3 Advantages : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 27
4 GenerationSystemDesign 28
4.1 Overview : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 28
4.2 InterfaceProtocols : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 31
4.3 Debugger Skeleton : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 34
4.4 GenerationFramework: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 36
5 Prototyp eImplementation 38
5.1 Overview : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 38
5.2 MaygenDebugger Features : : : : : : : : : : : : : : : : : : : : : : : : : : : 39
5.3 InterfaceProtocols : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 39
5.4 Debugger Skeleton : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 41
5.5 GenerationFramework: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 42
6 Results 43
6.1 Overview : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 43
6.2 TestCases : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 44
6.2.1 OPALandOM: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 44
6.2.2 CandMayy: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 47
7 Conclusions 53
7.1 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 53
7.2 FutureWork : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 54
7.2.1 MaygenPrototypeEnhancements : : : : : : : : : : : : : : : : : : : 55
7.2.2 RelatedAreas toExplore : : : : : : : : : : : : : : : : : : : : : : : : 55
A SLI Input FileTemplate 58
B MAI Input FileTemplate 65
CSampleOMVirtual MachineMAI Input File 73
1-1 An All-purpose Debugger Generation Sys tem : : : : : : : : : : : : 14
1-2 The Components of a Generated Debugger : : : : : : : : : : : : : : 14
1-3 Interrelati onshi p Among Maygen Us ers : : : : : : : : : : : : : : : : 16
4-1 T he Maygen Debugger Generati on System : : : : : : : : : : : : : : 29
4-2 T he C omponents of a Maygen Generated Debugger : : : : : : : : 30
3.1 C anoni cal Maygen Debugger Functi onali ty : : : : : : : : : : : : : 22
3.2 Addi ti onal Maygen Debugger Functi onali ty for Multi proces s
4.1 Source Language I nterface Routi nes : : : : : : : : : : : : : : : : : : 33
4.2 Machi ne Archi tecture I nterface R outi nes : : : : : : : : : : : : : : 33
4.3 Debugger Skel eton R outi nes Avai l abl e to Developers : : : : : :
5.1 Debugger Functi onali ty I mplemented I n Prototype : : : : : : : :
5.2 Debugger Functi onali ty Not I mplemented i n Prototype : : : : :
6.1 SLI R outi nes Supported By OPAL : : : : : : : : : : : : : : : : : : : : 44
6.2 SLI R outi nes Not Supported By OPAL : : : : : : : : : : : : : : : : : 45
6.3 MAI R outi nes Supported By OM : : : : : : : : : : : : : : : : : : : : : 46
6.4 MAI R outi nes Not Supported By OM : : : : : : : : : : : : : : : : : : 46
6.5 MAI Extens i on C ommands Provi ded By OM : : : : : : : : : : : : : : 47
6.6 Functi onali ty of the Generated OPAL Debugger : : : : : : : : : : 48
6.7 SLI R outi nes Supported By C : : : : : : : : : : : : : : : : : : : : : : : 49
6.8 SLI R outi nes Not Supported By C : : : : : : : : : : : : : : : : : : : : 49
6.9 MAI R outi nes Supported By Mayfly : : : : : : : : : : : : : : : : : : : 50
6.10 MAI R outi ne Not Supported By Mayfly : : : : : : : : : : : : : : : : 50
6.11 MAI Extensi on C ommands Provi ded By Mayfly : : : : : : : : : : : 51
6.12 Functi onali ty of the Generated C Debugger : : : : : : : : : : : : 52
7.1 Future Maygen Work : : : : : : : : : : : : : : : : : : : : : : : : : : : : 55
7.2 Debugger Generati on Systems : Areas to Expl ore : : : : : : : : : : 57
Int roduct i on
Recentyearshaveseenasurgeofnewcomputerarchitecturesasindustryandacademiawork
todevelopfasterprocessingpower. Withthepredominanceof high-level programmingover
machine-level programmingas well, theneedfor debuggingtoolsthatusesourcelanguage
namesandnotationshas increased. 1
Mucheorthas beengiventoautomatingthephases
of compiler writinginorder tosimplifyhigh-level languageimplementationfor these new
architectures. Similar eorts at automationhave not, unfortunately, been givento the
productionof debuggers.
Thislackofautomationindebuggerproductioncanproveexpensiveintermsof engineer-
inghours, andthusmonetarycosts, requiredfor development. Earlyoninthedevelopment
of anexperimentalcomputersystem,alow-leveldebugger isneededtoevaluatewhetherthe
systemisworkingcorrectly. Afterthenewcomputersystemisrunning, eachnewhigh-level
languagewrittenforthesystemrequiresacorrespondinghigh-level debugger becauseusers
wanttodebugintermsof thesymbolsandconstructsof thesourcelanguage. Onemethod
for meetingthese debuggingneeds wouldbe todevelopfromscratchanewdebugger for
eachnewarchitectureandfor eachnewlanguage implementedfor a givenarchitecture.
Unfortunately, writingdebuggersisnot onlytedious but alsotimeconsuming.
1
Theterms\high-level debugging,"\source-level debugging,"and\symbolicdebugging"areusedinter-
changeablytomeandebuggingofprograms interms of their source-level namesandconstructs.
Asimilarproblemconfrontedcompilerdevelopersaboutfteenyearsago. Compilation
technologyhas since thenfocusedonreducing duplicationof eort for various phases of
compilerimplementationwithconsiderablesuccess. Mostnotably, parsergenerators[Joh75,
MKR79, ASU86, FJ88], suchas yacc[Joh75], andscanner generators, suchas lex[ASU86,
FJ88], haveessentiallyeliminatedthemanualcreationof parsersandscanners, respectively.
Less knownbut alsoimportant havebeeneorts at automatingthe development of code
generators[GG78, DNF79, Bir82, LJG82] andevenentirecompilers[BBK
+
82, Ras82, Tof90,
Sto77, Sch88]. Maygenexplores the possibilityof applyingsimilarideas of automationto
debugger development.
1.1 Project Overvi ew
This thesis exploresanovel approachtoprovidingsource-level debuggingsupport through
the development of a\debugger generationsystem." Ingeneral, anall-purposedebugger
generationsystemmightbe atool that takesasinput asourcelanguagedescriptionanda
machinearchitecturedescription, 2
andproduces as output afullyfunctional, stand-alone,
language-dependent debugger for thespeciedarchitecture. Figure1-1depicts suchasys-
tem.
Adebugger producedbysuchagenerationsystemconsistsof acoredebugger skeleton
(SKEL) providedbythegenerator, asourcelanguageinterface(SLI) createdbythegener-
ator fromthe source language input, andamachinearchitectureinterface(MAI) created
bythe generator fromthe machinearchitectureinput. Figure1-2depicts the components
of suchagenerateddebugger.
The debugger generationsystemdesignedinthis project is calledMaygen.
3
Maygen
diers fromthe describedall-purposegenerationsysteminterms of what informationis
conveyedfromeachof the source language and machine architecture developers tothe
2
Details about theterms \sourcelanguage"and\machinearchitecture"canbefoundinSection4.2.
3
Thename\Maygen"originatedfromaninitial projectgoal of generatingvarioussymbolicdebuggersfor
onespecictargetarchitecture, theMayy[Dav92]. Theproject laterevolvedtoencompass various target
All-Purpose
Debugger
Generator Source
Language Description
Machine Architecture Description
Generated
Debugger Symbolic
Figure1-1: An All - purpos e Debugger Generati on System
Generated
Debugger
Symbolic =
Machine Architecture Interface (MAI)
(SLI)
Source Language Interface
(SKEL)
Debugger
Skeleton
generationsystem. Intheall-purposesystem, inputconsistsof sourcelanguageandtarget
architecturedescriptionsthat arethenusedbythe generator toautomaticallycreatethe
neededinterfaceroutines. Inthe Maygensystem, the maximal set of routines comprising
eachinterfaceis fullyspeciedbyMaygentotheusersof thegenerationsystem; theinput
fromtheusers contains informationthatconveystoMaygenwhichof thedenedinterface
routinesareavailable. Oncetheavailableinterfaceroutinesareknown, theMaygensystem
determineswhatadditionalcomponents(partsoftheSKEL)arenecessarytoprovideoverall
debugger functionalityas well as topromotethe smoothinteractionof thetwointerfaces
describedabove. TheMaygensystemframeworkmaintainsthedebuggerskeleton,interprets
the inputs, andperforms the necessary informationprocessing to create a stand-alone,
language-dependent andarchitecture-dependent debugger.
Figure 1-3 depicts the interrelationshipamongusers of the Maygensystem. Maygen
users canbe classiedintoone of twogroups. \Phase I" users workwiththe Maygen
systematdebuggergenerationtime, while\PhaseII"usersworkwithgenerateddebuggers
at debugger runtime.
Aprototypeof theMaygensystemhasbeendevelopedandtwotestsetshavebeenrun
todemonstratethe viabilityof suchasystem. Thetest sets include adeclarativeProlog-
likesourcelanguagerunningonatargetvirtualmachineemulatorandanimperativesource
languagerunningonatarget parallel, message-passingdistributed-memoryarchitecture.
1. 2 Thesi s Organi zati on
The remainder of this thesis describes the advantages anddisadvantages of relatedwork,
explainswhytheMaygengenerateddebugger isamorefeasibleapproach, andpresentsthe
design, implementation, evaluation, andachievementsof theMaygensystem.
Chapter 2begins bybrieyexaminingprevious researcheortsatprovidingdebugging
support for multiplelanguages.
Chapter 3presents the features of the canonical Maygendebugger incomparisonand
Generated
Debugger Symbolic
Architecture developer:
provides MAI routines and input
Language developer:
provides SLI routines and input
Maygen
Generation
Framework
Phase I
Phase II
Generated
Debugger Symbolic Debugger user:
uses generated debugger
Software
User
Legend:
Chapter 4thendescribes theMaygensystemdesign, includingthesourcelanguageand
machine architecture interface protocols, the core debugger skeleton, andthe generation
frameworkusedtocreatedebuggers.
Chapter 5elaborates upontheprototypeof theMaygensystemthat wasdeveloped, as
well as providessomeof the moreinterestingimplementationissues involved.
Chapter 6thendiscusses thetest cases usedtoevaluateboththecapabilities andthe
eectivenessof thegenerationsystemprototype.
Finally, Chapter 7summarizes the Maygenproject, presents the author's conclusions,
andspeculates uponpossibledirections forfurther researchintheareaof debugger gener-
ation.
Rel at ed Wor k
Theideaof debuggergeneration, althoughnosuchsystemisknowntoexistortoeverhave
beendesigned, wasproposedbyJohnson[Joh78] in1978. WhileJohnson'sownfocuswason
providingamultilingual tool fordebugging, hecommentedthat adebugger generationsys-
temcouldpossiblybeanalternativeapproachtoprovidingsource-level debuggingsupport
formultiplelanguages.
Despitethelackof previous workondebugger generation, tworelatedareas of research
haveprovidedsomeinsightfor the Maygenproject. Specically, the areas of multilingual
debuggingandlanguage-independent debuggingalsotrytoprovidedebuggingsupport for
multiplelanguages.
2. 1 Mul til i ngual Debuggi ng
Multilingualdebuggingisadebuggingstylethatpermitsthedebuggingof softwareinwhich
components have been written in more than one source language[Joh82]. Multilingual
debuggingis useful toconsiderbecauseof someissuesthat aresimilartothoseof debugger
generation. Specically, theneedtodistinguishbetweenlanguage-dependentandlanguage-
independent componentsof debuggerspertains toboth.
Twoexamples of multilingual debuggers areVAX DEBUG[Bea83] andSWAT[Car83].
VAXDEBUGistheVAX-11DebuggerdevelopedatDigital EquipmentCorporation. Fora
particularsetof supportedsourcelanguages,VAXDEBUGunderstands: howsymbolnames
arecomposedinthelanguage, howlanguageexpressionsareinterpreted,howandwhentype
conversions aredone inthe language, how values inthe language aredisplayed, andhow
thelanguagescoperules work. AlthoughVAXDEBUGunderstands this informationfor a
denedset of languages, it operates accordingtothe rulesof onlyone languageat atime.
VAXDEBUGsupports the followinglanguages: assembly, Fortran, Bliss, Basic, Cobol,
Pascal, andPL/I.
SWATis a source-level debugger developed by Data General Corporation. SWAT
supports ve high-level languages, eachof whichconforms toanagreedupon\Common
Compiler Component Methodology." This methodologydenes a commonintermediate
language, procedure-callingsequence, andlanguageruntimeenvironmentthat mustbefol-
lowedbyeachof the supportedlanguages. The languages understoodbySWAT are: C,
Cobol, Fortran77, Pascal, andPL/I.
2. 2 Language-i ndependent Debuggi ng
Similartotheideaofmultilingualdebuggingislanguage-independentdebugging. Language-
independent debugging refers todebugging techniques that are independent of anyone
particular source language[Joh82]. Adebugging systemthat has dealt specically with
the issue of language-independence is the RAIDEsystem[Joh77]. Johnsonexplains that
a separate debugginglanguagemight be desirable. The debugging language createdfor
the RAIDEsystem, calledDispel[Joh81], is designedto aidcommunicationbetweenan
interactiveuser andaruntime, symbolicdebuggingsystem.
2. 3 Advantages and Disadvantages
Indeed, theseprevioussystems present approachestodebuggingthat appear toaccommo-
tionas well as increasedeaseinproduct maintenance. Inaddition, these systems oer a
certainamount of functional consistencytothedebugger user.
Unfortunately,thesesystemshaveseveralshortcomings. First, theyareunabletohandle
the peculiarities of anyspecic language; there is noextensionmechanismwithwhichto
catertotheneeds of agivenparticularlanguage. Second, thelanguagessupportedbyeach
of themultilingual debuggers arespeciedbeforehand; tohandle another language would
meanhavingtorewritethedebugger itself. Thesesystemsarelimitedtodebuggingnotjust
apre-denedset of languages, but moreover, onlyapre-denedset of semanticallysimilar
languages.
Afurtherfaultliesinthelanguage-independentdebuggingsystemaswell. Ausermust
rst learnacompletelyseparatelanguage, thedebugginglanguage, beforeevenbeingable
tostartdebuggingaprogram. Once debuggingcanactuallyproceed, theuser thenneeds
toworryabout the possibilityof faultydebuggingprogramsinadditiontofaultysource
programs.
Admittedly, multilingual andlanguage-independent debugging techniques oer some
gains over single-language debuggers. Nevertheless, the deciencies in these debugging
Canoni cal Gener at ed Debugger
TheMaygendebuggertriestomaintainthedesirablefeaturesof multilingualandlanguage-
independentdebuggerswhilealsotryingtoimproveupontheir shortcomings. Thischapter
begins bydescribingthefeaturesof thecanonical Maygengenerateddebugger, proceeds to
explainthemotivationbehindthechosendesign, andthendemonstrateshowthisdesignis
abletooermorethanmultilingual andlanguage-independentdebuggers.
3. 1 Overvi ew
Thecanonical Maygendebugger generallyresembles atypical single-languagesource-level
debuggerforacompiledlanguageinthatitoersthe\traditional"functionalitywithwhich
usersareaccustomedtodebuggingprograms. TheMaygendebugger debugs compiledcode
that has not beenoptimized. It is alsoexpectedthat the user starts upthe Maygende-
bugger andthenruns aprogramunder debugger control. Themaximal set of fundamental
debuggingfacilitiesthataresupported 1
byaMaygendebuggerinclude: starting, stopping,
single-stepping, andcontinuinganexecution; loadingale; resettingthemachine; setting,
clearing, andlistingmachine-level as well as source-level breakpoints; activatingandsus-
1
Eachof thesupportedfacilitiesis onlyavailableuponsatisfactionof specicconditions. SeeChapter4
for details.
Table3.1: C anoni cal Maygen Debugger Functi onali ty
Startexecution
Stopexecution
Continueexecution
Single-stepexecution(followingcalls)
Single-stepexecution(not followingcalls)
Loadale
Reset themachine
Set, clear, listmachine-level breakpoints
Set, clear, listsource-level breakpoints
Activatebreakpoints
Suspendbreakpoints
Displayandset variablevalues
Displayregistervalues
Traceanduntracevariables
Traceanduntraceprocedures
List tracedvariables
List tracedprocedures
List user programlabels andsymbols
Showcurrent sourceline
Print informationabout debugger status
Displaylistof debugger commands
Repeat previous command
Quit Debugger
Comment(ignored)
pendingbreakpoints; displayingandsettingvariablevaluesandregistervalues; tracingand
untracingvariables andprocedures; listingtracedvariables andprocedures; indicatingthe
current source line; displayingalistof debugger commandswithhelpinformation; repeat-
ingthe previous command; quittingthe debuggingsession; andaddingacomment. The
Maygendebugger functionalityis summarizedinTable3.1.
Eachcommand'savailabilitydepends uponitssemanticcorrectnessinthecontextof the
particular source language or machinearchitectureinvolved, as well as uponthe support
adebuggerusershouldnotbeabletosetlogicvariablesinProlog; thus, thecommandtoset
thevalueof avariableisnotmadeavailableinageneratedPrologdebugger. Inthismanner,
eachgenerateddebugger is tailoredspecicallytotheparticular languageandarchitecture
inquestion.
Inadditiontothe fundamental debuggingfacilities, the Maygendebugger alsohas a
mechanismfor incorporatingextensioncommands that arethenfullyavailabletothe de-
bugger user. For example, the optiontochoose whether anexecutionwill proceedina
breadth-rst manneror adepth-rst manneris not providedbythecanonical Maygende-
bugger; however, thismightbeadesirablecommandtohaveinaPrologdebugger. AProlog
systemdeveloper, then, canspecifythis optionas anextensioncommandtothe Maygen
system, whichwill thenaddit tothe set of commands available inthe generatedProlog
debugger.
Extensioncommands canbespeciedandprovidedbythesourcelanguagedeveloper,
themachinearchitecturedeveloper, or both. Extensioncommands areof twogeneral a-
vors. \Independent"extensioncommandsareself-containedinthattheir functionalitydoes
notdependuponanyroutinesthat mightnot beavailable, e.g., fromeitherthesourcelan-
guageinterfaceroutineset or themachinearchitectureinterfaceroutineset. \Dependent"
extensioncommands, ontheother hand, arenot self-containedinthat their functionality,
andthus their availabilitytothedebugger user, depends uponat leastoneof theroutines
fromeither the sourcelanguageinterfaceroutineset or themachinearchitectureinterface
routineset.
2
Finally,thecanonicalMaygendebuggerunderstandsthatnotall machinesareuniproces-
sors; theMaygendebuggerunderstandsthatamachinemayhavemorethanoneprocessing
node. Insuchcases, theMaygendebuggeroperatesonasinglenodeatatime. Thedebugger
user has theabilitytodeterminethetotal number of processingnodes present, determine
2
Eithertypeof extensioncommand|independent ordependent|canuseroutinesexplicitlyprovidedby
thedebuggerskeletonifdesired. (SeeChapter4fordetails.) Sincetheavailabilit yof anextensioncommand
does not hinge uponthe availabilit yof routinesprovidedbythedebugger skeleton(because the latterare
alwaysavailable), debuggerskeletonroutinesdonot playaroleintheclassicationof extensioncommands
Table3.2: Addi ti onal Maygen Debugger Functi onali ty for Multi proces
Displaynumberof nodes presentandavailable
Showcurrent node
Switchtoadierentnode
Changenumber of nodes available
the number of nodes available, determine whichnode is beingdebugged, switchfromthe
currentnodebeingdebuggedtoadierentnode, andchangethenumberofnodesavailable.
Maygen's default mode of executionfor multiprocessorsis that whichis providedbythe
machinearchitecturedeveloper. Table3.2summarizestheadditionaldebuggerfunctionality
providedbyMaygenfor multiprocessorarchitectures.
3. 2 Desi gn
3.2.1 Debuggi ng Unopti mi zed Compil ed Code
The canonical Maygendebugger was developedtoworkonunoptimized, compiledcode
ratherthanonoptimizedorinterpretedcode. Althoughusinganinterpreterasthebaseof a
debuggermightbebenecial becauseof howwell it supportsinteractivedebugging[Mak91],
the approachis more complicated. Inadditionto a debugger skeleton, the generation
systemwouldneed tomaintainaninterpreter skeletonas well. This interpreter skele-
toneither wouldneedtointerpret a broadclass of source languages, whichis currently
infeasible[Joh77], or wouldneedtobedevelopedbythegenerationsystemintoalanguage-
dependent, architecture-dependentinterpreter. Thegenerationof suchaninterpretermight
itself be aninterestingresearchproblem, but is tangential totheissueof debugger genera-
tion.
Furthermore, Troisi[Tro82] points out that interpretedcode mayrundierentlythan
areaof the source code. Inaddition, adebugger baseduponaninterpreter might suer
fromsignicantlydecreasedexecutionspeed[Edw75].
Likewise,theissueofdebuggingoptimizedcodeisalsotangentialtotheprimaryconcern
of howtoautomaticallycreateasymbolicdebugger.
3
Thus,thecanonical Maygendebugger
expects thatthecodeauser loadsandthereforewantstodebugis unoptimized. Oncesuch
code hasbeendeterminedtobecorrect, thentheuser canexploreperformanceissues.
3.2.2 Pro vidi ng Tai lored, Traditi onal Functional ity
Thecanonical Maygendebugger oersavarietyof traditional debuggingcommandstothe
user. Suchadesignwaschosennot onlybecauseusersaremoreaccustomedtothismethod
of debuggingandthus canhavelessstartuptimelearninghowtouseaMaygendebugger,
butalsobecauseuserswouldbeprovidedwiththeessentialsofaruntimedebuggingsystem,
whichare the abilityto set breakpoints andexamine values withinthe programbeing
debugged[Bro79, Joh81].
Sometraditional debuggingcommands, suchas startinganexecution, makesensefor
essentiallyall languages. The relevance of some other commands, however, arenot nec-
essarilyimmediatelyapparent. For example, settingabreakpoint makes perfect sensein
alanguage suchas Cor Pascal; but, what does it meantoset abreakpoint inProlog?
It might, for example, meanthe abilitytotemporarilystopexecutionat anyof the four
ports of the multiportedboxmodel for Prologexecution[SW90]. Another exampleis the
tracingof variables. Thismightmakegoodsenseinanimperativelanguage, butwhatdoes
it meaninadeclarative one? Anexample of howthe tracingof variables couldbe used
inadeclarativelanguageis tofollowclauses thatmatch(aretrue) for aparticular search.
Incases suchas the twodescribed, it is left uptothelanguagedeveloper or architecture
developertodecideinwhatmannereachsupportedtraditional debuggingcommandcanbe
bestexploitedfor debuggingof thegivenlanguageonthegivenarchitecture.
3
3.2.3 Supp orti ng Extensi on Commands
Admittedly,not all of thetraditional debuggingcommandsarenecessarilyapplicableforall
sourcelanguages or all machinearchitectures. Forthis reason, theMaygendebugger might
onlyprovideasubsetof thetraditional commands, dependingonthespeciclanguageand
architectureinquestion. Thatis, theMaygendebuggerisspecicallydesignedtobecapable
of havingacommandset tailoredtothetargetlanguageandarchitecture.
This tailoringof the Maygendebugger's commandset goes beyondsimplydeletingir-
relevantorinapplicabletraditional debuggingcommands. Suchasystemwouldbenotonly
toolimitingfor theextremelyunconventional targetlanguageand/orarchitecture, butalso
not goodenoughfor amoreconventional but slightlydierent target languageand/or ar-
chitecture. Accordingly, theMaygendebuggerisdesignedtosupportextensioncommands.
Theextensioncommands enablelanguageandarchitecturedeveloperstoextendthebasic
commandset of aMaygendebugger toincludeanyadditionallydesiredfunctionalitythat
is potentiallyhighly-specicfor that particularlanguageor architecture.
3.2.4 Supp orti ng Mul ti processors
Althoughthe target architecture for Maygenmight be a parallel one, the focus of this
projectisondevelopingamethodfor generatingdebuggersratherthanondeterminingthe
bestwaytoimplementaparallel debugger. Thus, Maygendebuggershavebeendesignedto
dealonlywithsimplenotionsofparallelism,suchasknowingabouttheexistenceofmultiple
processingnodes. AMaygendebugger operatesononeprocessingnode at atimeandcan
switchfromonenodetoanother upontheuser's request. Thesecapabilitiesallowformore
meaningfuldebuggingonamultiprocessorthanpossiblefromadebuggerwithabsolutelyno
knowledgeof multiplenodes. Maygengenerateddebuggers donot, however, address more
complexparallelismissues, suchas the monitoringof interprocess communication. Such
issues, althoughpotentiallybenecial, wouldtendtodetract fromtheprimaryconcernof
3. 3 Advantages
Themoreobvious advantagesof usingMaygendebuggers overtraditional, single-language
debuggers aresimilartothe advantagesattributedtotheuseof multilingual or language-
independent debuggingtechniques. First, Maygendebuggers still present acertaindegree
of functional consistencytothedebugger user, resultinginlesslearningoverhead. Second,
Maygendebuggersarecheaptobuildsincetheyrequirelittleworkonthepartof language
developers andarchitecturedevelopers comparedtothe eort neededtocreatedebuggers
fromscratch. Finally, maintenanceis simpliedbecausethedrivingengineof thedebugger
is similar fromoneMaygendebugger tothenext.
WhileMaygendebuggerssharetheadvantagesofmultilingualandlanguage-independent
debugging systems over traditional, single-language debuggers, Maygendebuggers addi-
tionallycompensateforthedeciencies inherentinmultilingual andlanguage-independent
systems. Maygendebuggers are exible; they can be tailoredtothe specic needs and
peculiarities of dierent languages andarchitectures. This exibilitycomes inpart from
the selectiveavailabilityof thesupporteddebuggingroutines. Moreimportantly, though,
this exibilitycomes fromthesystem's allowanceof andsupport for extensioncommands.
These features takentogether result inasystemcapable of handlingsemanticallydier-
ent languages. Furthermore, Maygendebuggers canbe generatedfor more thanjust a
pre-dened, limitedset of languages.
Howis it that theMaygendebuggercanbesoexible? Theanswerlies inthefactthat
it is agenerateddebugger, thatit is generatedaccordingtothespecics of eachparticular
language and each particular architecture. This is made possible throughthe Maygen
Generat i on Sys t em Des i gn
4. 1 Overvi ew
The Maygensystemconsists of three major components: a set of interface protocols, a
debugger skeleton, andagenerationframework. The protocols specifytheexact natureof
theinterfaceroutines that promotesmoothcommunicationbetweenthedebugger skeleton
andtherestof theprogrammingenvironment.
1
Theroutines that areavailablefor agiven
debugger tobegeneratedareconveyedbywayof input les tothegenerationframework.
The generationframework, housing the debugger skeleton, processes the input dataand
produces astand-alone, language-dependent andarchitecture-dependent debugger.
Figure4-1portraysthecomponentsoftheMaygensystemandhowtheyareinterrelated,
whileFigure4-2showsthepieces of aMaygengenerateddebugger.
The Maygensystemwas designed inthis manner inorder to have the capabilityof
producingadebugger that is exible, interms of handlingverydierent inputs, yet prac-
tical, interms of providinglarge savings tolanguage andarchitecturedevelopers. Since
interpreter-baseddebuggers havesomeintrinsicproblems, thedebuggingof compiledcode
waschosenasthebasisforMaygen. Thedecisiontohaveagenerationsystematall evolved
1
The\restof theprogrammingenvironment"referstothe\sourcelanguage"and\machinearchitecture."
Theseareexplainedindetail inSection4.2.
Generated Debugger Generation
Framework
Skeleton Debugger
Interface Protocols
SLI routines MAI routines
File SLI Input
Input MAI
File
=
MAI
from
SLI
from Generated
Symbolic Debugger
Skeleton Debugger
(SKEL)
Figure4-2: T he C omponents of a Maygen Generated Debugger
fromtheknowledgethatnon-generateddebuggers, suchasmultilingualdebuggers, lackthe
exibilityneededtosupportanarbitrarynumber of languagesystemsas well as tohandle
semanticallydierentlanguagesystems. Ontheonehand, thegenerationaspect, tailoring
ability, andextensionmechanismof theMaygensystemmakecanonical Maygendebuggers
exible. Ontheotherhand, thecoredebuggerskeletonalongwiththeautomaticprocessing
of it intoagenerateddebugger makecanonical Maygendebuggerspractical.
Analternativemethodthatwasconsideredforachievingthedual goalsof exibilityand
practicalitywas toadddebuggingconstructs toasourceleinapreprocessing-typestep.
Preprocessorshavetheadvantagethatthecompiler of thesourcelanguagetobedebugged
neednot be modied[Edw75]. This method, however, seemedtobe extremelylimitingin
terms of what debuggingcapabilities adebugger user wouldhave, as well as interms of
4. 2 Interface Protocol s
Animportant aspect of developingtheMaygensystemis decidinguponthe interactionof
theMaygendebugger withtherestof theworld. Someprogramminglanguages employthe
notionof anabstract machine, or virtual machine, withwhichtoserveconceptual
2
and/or
implementational 3
purposes. Whenthisisthecase, thehighlevelaspectsof theabstraction
couldbe exploitedfor the purposes of debugging. Anexampleis the modicationof the
ports of thePrologboxmodel tosupport debugging[SW90].
Conventional languages suchas CandFortrando not reallyhave abstract machines
withwhichtovisualizetheir execution. For example, inaUnixsystem[MM83], anobject
leproducedbythe Ccompiler executes as just another process runningunder the Unix
operatingsystem. Conceptually,onemightvisualizethatprocesshavingacertainamountof
memoryallocatedtoitandhaveanotionof dataandinstructionsresidinginthatmemory,
aswellasa\locationcounter"thatindicatesthecurrentinstructionbeingexecuted. Clearly,
suchamental model of programexecutionis downnear thelevel of the operatingsystem
andmachinearchitectureonwhichtheprocessis running.
The Maygensystemadopts anintermediatepositiontowarddebuggers that attempts
totakeadvantageof higher levels of abstractionwhenavailable, but that canbe usedfor
lower-levelconventionalprogramsaswell. TheMaygensystemseparatesthesourceprogram
fromtheevaluationenvironment.
Accordingly, the twointerfaces tothe Maygendebugger are the source programand
theevaluationenvironment. Theinterfacetothesourcelanguageis ttinglyreferredtoas
the Source Language Interface (SLI). The interfacetothe evaluationenvironment is less
appropriatelyreferredtoas theMachineArchitectureInterface(MAI); thisinterfacemight
2
Asaconceptual technique, theabstractmachineallowsahighlevel waytothinkabouttheexecutionof
aprogram. Thiscapabilityisespeciallyuseful whentheprogramminglanguagecontains non-trivial control
mechanismssuchas Prolog's unicationor Snobol's patternmatcher.
3
Asanimplementationtechnique, theabstractmachinecanserveasaspecicationthatdescribesdetails
of aparticularalgorithm, suchasaunieror patternmatcher, usedtoimplementthelanguage. Inaddition,
theabstract machine canserveas animplementationprototype, as intheLispfunctions Eval andApply,
encompass not onlythe machine architecture, but alsoa runtime system, an operating
system, anabstractmachine, or acombination.
The interface protocols specifythe exact nature of the routines that are usedbythe
coredebugger tointeract withthe source programandthe architecture.
4
Eachinterface
protocol canbethoughtof asthesetof routinesthatcomprisetheinteractionbetweenthe
coredebuggerandsourceprogram,orbetweenthecoredebuggerandmachinearchitecture.
The Source Language Interface routines areprovidedbyalanguage developer, while the
MachineArchitectureInterfaceroutinesareprovidedbyasystemdeveloper.
Eachinterfaceconsistsof approximatelyfteenroutines; thesetranslatetothesupported
functionalityof agenerateddebugger. Thereexists aminimal subset of routines that are
requiredof the Source Language Interface andof the Machine ArchitectureInterface in
order for aworkingdebugger tobe generated. Withthe provisionof this minimal subset,
Maygencanautomaticallycreatealow-level debugger. Withtheprovisionof increasingly
moreSourceLanguageInterfaceandMachineArchitectureInterfaceroutines, Maygencan
createsymbolicdebuggers withincreasinglylarger amountsof functionality. Thesesetsof
interfaceroutines areexperimentallyderived.
Table4.1lists the routines constitutingthe Source Language Interfaceas speciedby
thecurrentMaygendesign. Similarly, Table4.2liststheroutinescontainedintheMachine
ArchitectureInterfaceas speciedbythecurrent Maygendesign.
Theinterfaceprotocolsnot onlyspecifythe routines that shouldbeprovided, but also
theformatinwhichsuchinformationis conveyedtothegenerationframework. Theinput
tothegenerationframeworkconsistsof twotextles, onefor informationabouttheSource
LanguageInterfaceandtheotherforinformationabouttheMachineArchitectureInterface.
TheSourceLanguageInterfaceinputlecontains: alistingoftheSourceLanguageInterface
routines with specication of whether or not each is available, the name of the source
language, the locationand name of a librarycontainingthe Source Language Interface
4
Henceforth, the \machine architecture" andthe \architecture" refer to the evaluationenvironment,
Table4.1: Source Language I nterface R outi nes
InitializeSLI
Mapproceduretoobject line
Mapprocedurebeginningtoobject line
Mapprocedureendingtoobject line
Traceprocedure
Mapsourcelinetoobjectline
Readinsymbols
Print labels
List procedures
Print symbols
Displaytext of currentsourceline
Untraceprocedure
Process initial debugger arguments
Print SLI information
Table4.2: Machi ne Archi tecture I nterface R outi nes
InitializeMAI
Is programloaded?
Install machinebreakpoint
Continueprogram
Uninstall machinebreakpoint
Set machinebreakpoint onaprocedure
Clearmachinebreakpointonaprocedure
Readinprogram
Printregister contents
Runprogram
Step, followingprocedurecalls
Step, notfollowingprocedurecalls
Reset machine
Processinitial debugger arguments
PrintMAI information
Changecurrentprocessingnode
routines, andinformationabouteachextensioncommanddesiredbythelanguagedeveloper.
This extensioncommandinformationincludes the total number of extensioncommands
supportedbythe language developer as well as details about eachextensioncommand.
Thesedetails include: thenameof thecommand, the declarationusedtoindicateit is an
externallydenedprocedure, theinvocationof thecommandwithitsarguments, andalist
of Source LanguageInterfaceandMachineArchitectureInterfaceroutines uponwhichthe
proper functioningof theextensioncommanddepends.
5
Similarly,theMachineArchitectureInterfaceinputlecontains: alistingoftheMachine
ArchitectureInterface routines withspecicationof whether or not eachis available, the
nameof thearchitectureorabstractmachine, thelocationandnameof alibrarycontaining
the MachineArchitecture Interface routines, andinformationabout eachextensioncom-
manddesiredbythemachinedeveloper. Theinformationfortheseextensioncommandsis
exactlyanalogous tothat of the extensioncommands for the Source Language Interface.
TheMachineArchitectureInterfaceinput leadditionallycontainsinformationabout how
manyprocessingnodes arepresent as well as how manyprocessingnodes areavailablein
thetargetarchitecture.
Anexampleof aSource Language Interfaceinput letemplate, whichcanbe lledin
byalanguagedeveloper, canbefoundinAppendixA. AppendixBcontainsanexampleof
aMachineArchitectureInterfaceinput letemplate.
4. 3 Debugger Skel eton
Thedebugger skeletonconsists of the componentsof asymbolicdebugger that havebeen
determinedtobe language-independent andarchitecture-independent. Thesecomponents
havebeengroupedtogethertoformthecoreof adebugger, hencedebuggerskeleton, which
theMaygensystemuses as thebackbonewithwhichtocreateMaygendebuggers.
Thedebugger skeletoncanbethoughtof as providingthegluenecessaryfor coherently
5
stickingtogether the interfaceroutines. Moreaccurately, the debugger skeletonis several
les of code, some of whichcontribute directly(unchanged) tothe code of a generated
debugger, andsomeof whichareeither supersets of or incompletefragmentsof code that
willbemodiedbythegenerationframeworkintocodethatwill thenbepartof agenerated
debugger. Thenal outputlesincludeamakelewithwhichtheusercanmakethenewly-
generateddebugger fromitssourcecode.
Moredescriptively, the debugger skeletonconsistsof debugger componentssuchas the
debugger user interface, commandloopdriver, andgrungyinitializationandmaintenance
routines, e.g., for keepingtrackof tracing. The debugger user interface canrange froma
simpletextual interfacetoamuchmoreelaborategraphical user interface. This interface
needonlybe writtenonce andthencanbe usedfor eachsubsequent Maygendebugger.
Anexample of a grungymaintenance jobis the breakpointingfacility: coordinatingthe
setting(andcheckingfor duplicates), clearing(andcheckingfor validity), keepingtrack,
listing, installing,uninstalling, activating,andsuspendingof machine-levelandsource-level
breakpoints.
Eachdebugger commandsupportedbythedebugger skeletonis aliatedwithcertain
SourceLanguageInterfaceandMachineArchitectureInterfaceroutinesuponwhichitsfunc-
tionalitydepends. Agiven, supporteddebugger commandis onlyavailableif theroutines
uponwhichit depends aremadeavailablebythelanguageand/or architecturedevelopers.
For example, the commandthat allows a debugger user toset abreakpoint onasource
linedepends upononeMachineArchitectureInterfaceroutine(install machinebreakpoint)
andone Source Language Interface routine (mapsource line toobject line). If either of
theseroutines is not supported, thenthe source-level breakpoint settingcommandis un-
availableinthe subsequentlygenerateddebugger. The debugger commands supportedby
thedebugger skeletonareidentical tothosepreviouslydescribedinTable3.1.
As mentionedpreviously, afewdebugger skeletonroutines are explicitlyprovidedto
aidMaygensystemusers. Language or architecture developers canfreelycall theserou-
Table4.3: Debugger Skel eton R outi nes Avai lable to Devel opers
Install breakpoints
Uninstall breakpoints
Checkwhether breakpoint address alreadyexists
Addproceduretolistof procedurebreakpoints
Removeprocedurefromlistof procedurebreakpoints
Addmachineaddresstolistof machinebreakpoints
Removemachineaddressfromlistof machinebreakpoints
routines supportedinthis manner arelistedinTable4.3.
4. 4 Generati on Framework
This sectiondescribes the overall frameworkusedbythe Maygensystemtocreateafunc-
tional debugger. This frameworkserves as thedrivingenginefor acceptinginput informa-
tionabout the Source Language andMachineArchitectureInterfaces, for translatingthe
input intowhichdebugger commands will be available, andfor appropriatelymodifying
andappendingthedebugger skeletontomakeit astand-alonedebugger.
Thegenerationframeworkunderstands theformatof theinput lesandthus canread
andinterprettheinformationintheinput. Thegenerationframeworkalsohouses, ormore
accurately, keeps trackof, all the pieces of the debugger skeleton. The frameworkknows
whichpieces aretobeleft intact tobecomepartof agenerateddebugger as well as which
needtobeeither augmentedor choppedandspliced.
The generationframeworkdecides, baseduponwhichSource Language Interface and
Machine ArchitectureInterfaceroutines areknowntobe available, what components will
gointothedebugger tobegeneratedandhowthesecomponentsshouldbeputtogetherto
makeaworkingunit. Theframeworkprocesses theinput informationtodeterminewhich
debuggercommandswillcomprisethecommandsetofthedebugger tobegenerated. These
thecodethat implementsthesecommands areincorporatedintothesourcecodeles that
compile intothe functional debugger. Finally, the generationframeworkoutputs all the
necessarycodeles andamakelefor thenew Maygendebugger.
The frameworkis designedtoperformat generationtimeall of theinterpretationand
processingnecessaryforagivendebuggertobegenerated. Byperformingallinputinterpret-
ingandprocessingduringdebugger generation, Maygendebuggers canavoidunnecessary
runtimeineciency.
Pr ot ot ype I mpl ement at i on
TheMaygensystemdesignencompassesmorethandoestheprototypethathasbeenimple-
mentedthusfar. Thischapterdescribes theenvironmentinwhichthesystemwasdeveloped
andthescopeof theprototype, as well aspresentssomeof themoreinterestingimplemen-
tational details.
5. 1 Overvi ew
The experiment was carried out using the equipment and facilities of Hewlett Packard
Laboratories. Asingle-processor workstationHP9000/840running HP-UX7.0, Hewlett
Packard'sversionofUNIX, wasusedforthedevelopmentofthedebuggergenerationsystem.
TheprototypeMaygensystemis writtenintheClanguage.
TheprototypegenerationsystemconsistsoftheSourceLanguageInterfaceandMachine
ArchitectureInterface protocols withroutines denedandinput le formatsspecied, an
implementedsubset of thedesigneddebugger skeleton, andafunctional generationframe-
workthat handles theexistingdebugger skeletonandinputs.
5. 2 Maygen Debugger Features
Thecanonical Maygendebugger of the prototypegenerationsystemsupports mostof the
functionalitysupportedbythat of thedesignedsystem. Thesecommands aresummarized
inTable5.1. The commands that arenot supportedinthis implementationare listedin
Table5.2. Anadditional noteis that thesupport for tracinganduntracingof procedures
is currentlyimplementedas the settingandclearingof breakpoints onprocedurenames.
Tracingof procedures couldbemademoreelaboratebynotonlybreakingwhenaprocedure
is reached, but alsoautomaticallydisplayingthevaluesof theprocedure's argumentsupon
invocationanddisplayinganyreturnvalueuponexit.
As inthe design, eachdebugging command's availabilitydepends upon its semantic
correctness inthe context of the particular source language or machine architecturein-
volved, as well asuponthesupportprovidedbyboththesourcelanguageandthemachine
architecturedevelopers.
The prototype canonical Maygendebugger is able tosupport one of the twoavors
of extensioncommands describedinSection3.1. Independent extensioncommands are
currentlyincorporatedinthe prototype, whereas dependent extensioncommands arenot.
Finally, theprototypeMaygendebugger operates onasinglenodeat atime,but under-
stands thattheremightbemorethanoneprocessorinthetargetarchitecture. Thus, when
thetargetarchitecturehas multiplenodes, thegeneratedMaygendebugger allowstheuser
to: determinethetotal numberof nodes present, determinehowmanynodes areavailable,
ndout whichnode is beingdebugged, switchbetweennodes, andchangethe number of
nodes available. This functionalityis identical tothat designed, whichis summarizedin
Table3.2.
5. 3 Interface Protocol s
The Source Language Interface and Machine Architecture Interface are implementedas
Table5.1: Debugger Functi onali ty I mplemented I n Prototype
Startexecution
Stopexecution
Continueexecution
Single-stepexecution(followingcalls)
Single-stepexecution(not followingcalls)
Loadale
Reset themachine
Set, clear, listmachine-level breakpoints
Set, clear, listsource-level breakpoints
Activatebreakpoints
Suspendbreakpoints
Displayregistervalues
Traceanduntraceprocedures
List user programlabels andsymbols
Showcurrent sourceline
Print informationabout debugger status
Displaylistof debugger commands
Repeat previous command
Quit Debugger
Comment(ignored)
Table5.2: Debugger Functi onal i ty Not I mplemented i n Prototype
Displayandset variablevalues
Traceanduntracevariables
Listtracedvariables
tionenvironment. ThespeciedroutinescomprisingtheSourceLanguageInterfacearethe
sameas thoselistedinTable4.1; likewise, the speciedroutines comprisingthe Machine
ArchitectureInterfacearethesameas thoseenumeratedinTable4.2.
The input le formats, whichthe Maygenprototype uses, are identical tothosepre-
scribedbythe interface protocol designof Section4.2. ThesampleSource Language In-
terfaceinput letemplatelocatedinAppendixAis theactual input letemplateusedfor
theprototype's languagetest cases. Similarly, the sampleMachineArchitectureInterface
input le templatelocatedinAppendixBis the actual input le template usedfor the
prototype'sarchitecturetestcases.
5. 4 Debugger Skel eton
The prototype debugger skeletonconsists of componentsof asymbolicdebugger that are
language-independent andarchitecture-independent, as designed. However, theprototype
debugger skeletondoes not encompass as muchbasicsupportedfunctionalityas does the
designeddebuggerskeleton. Also, thedebugger user interfaceis apurelytextual one.
Thecommandloopdriver is baseduponaClanguageswitchstatementthat switches
onthe interactive user's typedcommand. This implementationwas chosenfor relative
eciencyincarryingout the desiredcommandandfor easeintailoringthe appropriate
code les totheinputs.
The debugger skeletonconsists of ve les that contributeunchangedtoagenerated
debugger's sourcecodeandsixles that aremodiedintoles that arethendirectlypart
of agenerateddebugger's sourcecode. Theles that contributeunchangedcontainsource
codelesthatimplementbreakpoints,essential debuggerinitializationsanddriverroutines,
andinput/output routines. These les alsoincludeheader les that list Source Language
Interface, MachineArchitectureInterface, anddebugger skeletonroutines.
The les that needtobe modiedbefore becomingpart of agenerateddebugger are
the makele, \cases"le, \ller" le, extensioncommandle, \miscellaneous"le, and
toperformfor eachcommand. Whenthe prerequisite routines are available for agiven
debugger command, that commandwill be associatedwithcodethat performs the actual
command; whenthe prerequisiteroutines are not available, however, that commandwill
beassociatedwithcodethatrelaystotheuser theunavailabilityof theinvokedcommand.
Inaddition, eachcommandis accordinglyaddedor not addedtothe debugger helplistin
the\debugger helplist"le. Thus, whenauser callsupahelplistof debugger commands,
those commands that arenot available, due tolackof sucient support fromeither the
languageorarchitecturedeveloper,willnotbeincludedinthelist. The\ller"leiscreated
byMaygentoaccount for all of theSourceLanguageInterface andMachineArchitecture
Interfaceroutinesthatarenotprovidedasinputs. Maygencreates\ller"routinestosatisfy
thecompiler'schecks, knowingthat thesedummyroutines will notactuallybecalled. The
extensioncommandleiscreatedbyMaygentohandlethecallingof appropriateextension
commandsuponauser's invocationof suchcommands. Finally, the\miscellaneous"leis
createdbyMaygentoholdtwoarchitecture-dependent denitions as well as routines for
printinginformationupondebugger startupandexit.
5. 5 Generati on Framework
Theprototypegenerationframeworkis as describedinSection4.4. Thisgenerationframe-
workunderstands the input leformats, reads andinterprets the input les, accordingly
performs theactual modifyingof thedebugger skeletonles describedintheprevious sec-
Res ul t s
Thischapterdiscussesthetestcasesusedtoevaluatetheprototypegenerationsystem, and
hencetheMaygensystemdesignitself.
6. 1 Overvi ew
Thegoal for choosingthe testcases wastoselect domainsthat arequitedierent inorder
toshowthe exibilitythat Maygenhas incomparisontoexistingsystems for providing
debuggingsupport tomultipleprogrammingenvironments. Eachtestset
1
is comprisedof
asource language that conforms tothe Source Language Interface protocol (interms of
interfaceroutinesandMaygeninput le), andamachinearchitecturethat conformstothe
MachineArchitectureInterfaceprotocol (interms of interfaceroutines andMaygeninput
le).
TwosuchtestsetshavebeenrunthroughtheMaygensystem. Thetwosourcelanguages
andtheir evaluationenvironmentsare: adeclarativelanguage, OPAL, runningontheOM
virtualmachine,andanimperativelanguage, C,runningontheMayyparallelarchitecture.
By generating a symbolic debugger for both a declarative language andan imperative
language, Maygendemonstratesitsabilitytohandlesemantically-dierentlanguages.
1
A \test set"consistsof bothasourcelanguage\test case"andamachinearchitecture\test case."
Table6.1: SLI R outi nes Supported By OPAL
InitializeSLI
Mapproceduretoobject line
Mapprocedurebeginningtoobject line
Readinsymbols
Print labels
Print symbols
Print SLI information
Process initial debugger arguments
6. 2 Test Cases
6.2.1 OPAL and OM
OPAL, the OregonParallel Logic language, is a Prolog-like language developedat the
Universityof Oregon[Con90, Con91, Con92]. OPALis basedon the AND/ORProcess
Model[Kac90], whichis anabstract model for parallel logicprograms. TheAND/OR Pro-
cessModel hasanoperationalsemanticsdenedbyasynchronousobjectsthatcommunicate
entirelybymessages.
OPAL programsarecompiledintotheinstructionsetoftheOPALMachine,orOM. The
OMisavirtual machinesimilartotheWarrenabstractmachine[War83] forstandardProlog
implementations. The dierenceis that the OMvirtual machineis designedfor programs
thatexecuteaccordingtotheAND/ORProcessModel onnonsharedmemorymultiproces-
sors. The versionof the OMvirtual machineusedfor this testset runs onauniprocessor
UNIXworkstation; it does not exploitANDorOR parallelisminthisimplementation.
The OPALlanguagetest casesupports eight out of the fourteenSource Language In-
terface routines speciedbythe Maygenprototypeandprovides noextensioncommands.
The routines supportedbyOPALaresummarizedinTable6.1, while those that are not
supportedarelistedinTable6.2.
Table6.2: SLI R outi nes Not Supported By OPAL
Mapprocedureendingtoobject line
Traceprocedure
Mapsourcelinetoobject line
List procedures
Displaytext of current sourceline
Untraceprocedure
tecture Interfaceroutines speciedbythe Maygenprototype. Additionally, the OMtest
caseprovides twelveindependent extensioncommands.
The OMvirtual machine supports all of the Machine ArchitectureInterface routines
except the tworoutines specic tomultiprocessors since the OMimplementationis for a
uniprocessor. Tables 6.3and6.4summarizethoseroutines supportedandnot supported,
respectively, bytheOMvirtual machine.
The extensioncommands providedbythe OMvirtual machine provide the debugger
user withthe capabilities tochoose between: searchingfor all solutions or for just one
solution, performingabreadth-rstoradepth-rst search, executinginquiet modeor not,
tracingprocessesor notduringexecution, tracinginstructions ornotduringexecution, and
displayingregisters symbolicallyor not. The extensioncommands alsoenable theuser to
printsections of object code, sections of theheapbeingusedbythe OMvirtual machine,
messageorprocessinformation,queuecontents,andaprocesstreefortheexecution. These
additional features are summarizedinTable 6.5. Asample OMMachine Architecture
Interfaceinput lecanbefoundinAppendixC.
The Maygengenerationframeworkacceptedthe input les of the described test set
andproduceda symbolic debugger for OPALrunningonthe OMvirtual machine. The
debugger commands supportedbythegeneratedOPALdebugger arelistedinTable6.6
The OPALSource Language Interface input le andthe OMMachine Architecture
Table6.3: MAI R outi nes Supported By OM
InitializeMAI
Is programloaded?
Install machinebreakpoint
Continueprogram
Uninstall machinebreakpoint
Set machinebreakpoint onaprocedure
Clearmachinebreakpointonaprocedure
Readinprogram
Printregister contents
Runprogram
Step, followingprocedurecalls
Step, notfollowingprocedurecalls
Reset machine
PrintMAI information
Processinitial debugger arguments
Table6.4: MAI R outi nes Not Supported By OM
Changecurrentprocessingnode
Table6.5: MAI Extensi on C ommands Provi ded By OM
Toggleall-solutions
Togglebreadth-rst search
Togglequiet mode
Toggleprocess trace
Toggleinstructiontrace
Togglesymbolicregisterdisplay
Printcode
Printheap
Printmessageinformation
Printprocess information
Printqueuecontents
Printprocess tree
Maygen. ThesupportedfunctionalityofeachresultingOPALdebuggervariantwaschecked
toascertainthat the debuggers changedaccordingly. These generatedOPALdebugger
variantswerethentestedonasuiteof OPALprogramstoverifytheircorrectness.
6.2.2 Cand Mayy
The language of the secondtest set is C, the familiar, imperative language developedby
Ritchie[KR88, KW91]. C is arelativelylow-level, general-purposeprogramminglanguage.
WhileCprovides datatypes andfundamental control-ow constructions suchas looping
anddecisionmakingfor single-threadedcontrol ow, it does not provide built-inhigher-
levelmechanismssuchas input/outputfacilitiesoroperationsoncompositeobjectssuchas
listsandarrays.
CompiledCprograms areprocessedbythe Mayyarchitecture[Dav92]. The Mayy,
developedat Hewlett PackardLaboratories, serves as aback-endprocessor for aHewlett
PackardSeries 800 workstation. The Mayyis a scalable, general-purpose parallel pro-
cessingarchitecture; itisadistributedmemorymachinewithcommunicationsupportedby
Table6.6: Functi onali ty of the Generated OPAL Debugger
Printhelpinformation
Repeat previous command
Activatebreakpoints
Set breakpoint onobject line
Set procedurebreakpoint(traceprocedure)
Continuefrombreakpointorstep
Deletebreakpointonobject line
Deleteprocedurebreakpoint (untraceprocedure)
Readincompileduser program
Displaygeneral registers
Printinformationabout debugger status
Listbreakpoints
Listuserprogramlabels
Listuserprogramsymbols
Quit debugger
Runprogram
Singlestep(followcalls)
Singlestep(donot followcalls)
Suspendbreakpoints
Reset machinetostartupstate
Comment(ignored)
Executeanextensioncommand:
- Toggleall-solutions
- Togglebreadth-rst search
- Togglequiet mode
- Toggleprocess trace
- Toggleinstructiontrace
- Togglesymbolicregister display
- Printcode
- Printheap
- Printmessageinformation
- Printprocessinformation
- Printqueuecontents
Table6.7: SLI R outi nes Supported By C
InitializeSLI
Mapsourcelinetoobjectline
Mapproceduretoobject line
Mapprocedurebeginningtoobject line
Mapprocedureendingtoobject line
List procedures
Readinsymbols
Process initial debugger arguments
Print SLI information
Table6.8: SLI R outi nes Not Supported By C
Traceprocedure
Untraceprocedure
Print labels
Print symbols
Displaytextof currentsourceline
TheC languagetest casesupports nine out of the fourteenSource LanguageInterface
routines speciedbythe Maygenprototype andprovides no extensioncommands. The
routines supportedbyC aresummarizedinTable6.7, whilethosethatarenot supported
arelistedinTable6.8.
TheMayyarchitecturetestcasesupports sixteenoutof theseventeenMachineArchi-
tectureInterfaceroutinesspeciedbytheMaygenprototype. TheMayytestcasesupports
all of theMachineArchitectureInterfaceroutines except executionsteppingthatdoes not
followprocedure calls. Tables 6.9and6.10summarize those routines supportedandnot
supported, respectively, bytheMayytestcase.
Table6.9: MAI R outi nes Supported By Mayfly
InitializeMAI
Is programloaded?
Install machinebreakpoint
Continueprogram
Step, followingprocedurecalls
Uninstall machinebreakpoint
Set machinebreakpoint onaprocedure
Clearmachinebreakpointonaprocedure
Readinprogram
Printregister contents
Runprogram
Reset machine
Processinitial debugger arguments
PrintMAI information
Changecurrentprocessingnode
Changenumber of availablenodes
Table6.10: MAI R outi ne Not Supported By Mayfly
Step, notfollowingprocedurecalls
giveusersthecapabilitytoselectwhichCPUof thecurrentprocessingnodetodebug. Each
MayyprocessingnodehastwoCPUs: theMessageProcessor(MP)andtheExecutionPro-
cessor(EP). TheMayyextensioncommandsprovidethedebugger user withthefollowing
capabilities: toselect the MPof the current node for debugging, toselect the EPof the
current nodefor debugging, andtodeterminewhichCPUis thecurrent (beingdebugged)
CPUof agivenMayyprocessingnode. Theseadditional featuresaresummarizedinTable
6.11.
Table6.11: MAI Extensi on C ommands Provi ded By Mayfly
Select MP of current node
Select EPof current node
DeterminewhichCPUis current CPU
andproducedaCdebugger for the Mayy. The debugger commands supportedbythe
generatedCdebugger arelistedinTable6.12
The CSource Language Interfaceinput le andthe MayyMachineArchitectureIn-
terface input le were testedtohave varyingnumbers of interface routines available to
Maygen. The resulting Cdebugger variants were inspected toensure that their set of
supportedfunctionalitychangedaccordingly. As observedfor the OPAL/OMtestset, the
supportedfunctionalityof eachresultinggeneratedCdebugger alsocorrectlyreectedthe
changedMaygeninputs.
Duetologisticaldiculties, 2
thegeneratedCdebuggervariantswere\tested"byclosely
watchingthecommandsattemptedtobe writtentotheMayymonitor, thesoftwarethat
connectstheMayyarchitecturewithitsfront-endworkstation. Interfacingtothismonitor
istheMayy'sdebuggerlibrary. Normally, anydebuggerfortheMayycallsbasicroutines
fromthis debugger library. The debugger libraryroutines, whichnormallycommunicate
directlywiththeMayyviathemonitorprogram, werereplacedduringtestingwithverbose
stubs. AttemptedcommandwritestothemonitorfromgeneratedCdebuggervariantswere
thencomparedwiththeattemptedcommandwritesofsimilardebuggingcommandsinvoked
fromanexisting, testeddebugger for theMayy.
2
TheMayyarchitecturecanonlybeusedlocallybecauseitssoftwarecurrentlydoesnot supportremote
