0707070000020024621006440001460001440000010224460367445476100000500000000003Size20 0707070000020033021007770001460001440000010216540367445470100001000000001675Install Name=`cat ./Name` ln ./libmon.a /usr/lib if [ "$?" != "0" ] then echo "\n\n\nCouldn't install $Name.\nInstallation has been aborted." echo "\n\nPress Return to continue." read x exit 1 fi ./STICKDOCS chgrp bin /usr/lib/libmon.a chown bin /usr/lib/libmon.a chmod 644 /usr/lib/libmon.a cat < 037777777777 (or 0177777<<16 for the same accuracy) 077777 --> 01777777777 (or 077777<<16 for the same accuracy) Press Return to continue END read x exit 0 0707070000020032641007770001460001440000010224570362121556600000700000000076Removeecho"\n\n\nRemoving Library Monitor" rm -f /usr/lib/libmon.a 0707070000020035501007770001460001440000010224540367445462100001100000000044MAKEcpiocat Files | cpio -ocBv > MONITOR+IN 0707070000020035301006440001460001440000010156520367445371200000500000000042NameMonitor Library - from THE STORE! 0707070000020026451006660001460001440000010224470367445511200000600000000131Files./Size ./Install ./Remove ./MAKEcpio ./Name ./Files ./libmon.a ./STICKDOCS ./Profile.lib 0707070000020035271006440001460001440000010224610362121207600001100000002320libmon.alibmon.aE>monitor (mon.oEfdRER.textb .dataR@.bssNVHJfJgzp.p/p//N ./<NX-@m$./9/.NPg.NJm .N`& d . @-HB . " # 9ְl n e`# y  y!n  y!n 9ЀѮ 9֑ . R" -@ .o .` .-@ .rS.N-@ .r-@ .Ѐ-@ 9ЀЮ#./././.N LN^Numon.outmon.out. @F V\f nx~(p .filegmon.c.text.data.bssssizsbufmonitorprofilcreatwriteperrorcloseldiv__0707070000020033271007770001460001440000010232140367445403400001200000001400STICKDOCS# CHANGE THE VALUES ON THE FIRST TWO LINES AS APPROPRIATE NAME="PROFILING" LISTDOCS="Profile.lib" FOLDER=/u/$LOGNAME/Filecabinet/DOCS DEST=$FOLDER/$NAME if [ -d $FOLDER ] then if [ ! -d $DEST ] then mkdir $DEST chown $LOGNAME $DEST fi message -i "Document file(s) called $LISTDOCS will be placed in your DOCS/$NAME folder.\n\nThese files contain information about $NAME.\n\nTouch to continue." else message -i "A folder called DOCS/$NAME is being created in your Filecabinet. Document file(s) $LISTDOCS will be placed there.\n\nThese files contain information about $NAME.\n\nTouch to continue." mkdir $FOLDER mkdir $DEST chown $LOGNAME $FOLDER chown $LOGNAME $DEST fi for i in $LISTDOCS do ln $i ${DEST}/$i chown $LOGNAME ${DEST}/$i done 0707070000020033231006440001460001440000010232210367445445000001400000005307Profile.libNotes: (1) To include new monitor(3) library call, include "-lmon" on load line (before libc!). (2) The monitor(3) man page description to profile an entire program is incorrect. The call is: monitor((int(*)())0x80002,&etext,buf,bufsize,nfunc) (3) If you call profil(2), the scale must be a 32 bit (not 16 bit) scale. For example: man page corrected (32 bit) value ------------ ------------------------ 0177777 --> 037777777777 (or 0177777<<16 for the same accuracy) 077777 --> 01777777777 (or 077777<<16 for the same accuracy) =================== The following is explanatory in nature: =================== FROM: j.d.harper TO: mtuxn!4341fah DATE: 25 Apr 1986 16:05 EST SUBJECT: re: monitor(3) Fred: Profiling is used to get an idea of how much time is spent in each subroutine in a program. The easiest way to use it is to compile a program with "cc -p". This compiles the program with mcrt0.o (instead of crt0.o), which calls "monitor(3)" prior to running main(). monitor() calls the system call profile(2), which tells the operating system to keep a count of time spent in subroutine calls. An output file is created when the program exits that has counts and times for each subroutine. The information in this file (mon.out) can be easily examined by running the program prof(1); monitor(3) can also be called by a user. It can be used to keep track of certain parts of a program. The fix to monitor was to change its call to profile(2). profile(2) tells the operating system the granularity of time counting. That is, the operating system maps the address of the current position of a program into an array at every clock tick. The mapping can be as small as a one to one count, or many bytes can be mapped to one byte in the array. One argument to profile is a mask that tells the operating what the granularity of mapping should be. In Version 3.0, profil(2) needs a 32 bit mask. However, monitor(3) uses a 16 bit mask in its call to profil(2). The fix is to change the mask into a 32 bit mask. In order to use this new monitor(3), you must compile with a new library, libmon.a, which is what the MONITOR install gives you. By the way, the man page for profile(2) is wrong. It incorrectly says to use a 16 bit mask. The man page for monitor(3) is also wrong. It incorrectly tells the user to use address 0x02 for the start of a program, when it should be 0x80002. The user is told this piece of information during the MONITOR installation procedure. The source I used is 3.0 source that we got from Freehold. I guess this explanation is a bit long winded, but I think it explains both profiling and the monitor fix. Julia Harper mtuxn!mtung!jdh 0707070000020033231006440001460001440000010232210367445445000001300000000000TRAILER!!!reated when the program exits that has counts and times for each subroutine. The information in this file (mon.out) can be easily examined by running the program prof(1); monitor(3) can also be called by a user. It can be used to keep track of certain parts of a program. The fix to monitor was to change its call to profile(2). profile(2) tells the operating system the granularity of time counting. That is, the operating system maps the address of the current position of a program into an array at every clock tick. The mapping can be as small as a one to one count, or many bytes can be mapped to one byte in the array. One argument to profile is a mask that tells the operating what the granularity of mapping should be. In Version 3.0, profil(2) needs a 32 bit mask. However, monitor(3) uses a 16 bit mask in its call to profil(2). The fix is to change the mask into a 32 bit mask. In order to use this new monitor(3), you must compile with a new library, libmon.a, which is what the MONITOR install gives you. By the way, the man page for profile(2) is wrong. It incorrectly says to use a 16 bit mask. The man page for monitor(3) is also wrong. It incorrectly tells the user to use address 0x02 for the start of a program, when it should be 0x80002. The user is told this piece of information during the MONITOR installation procedure. The source I used is 3.0 source that we got from Freehold. I guess this explanation is a bit long winded, but I think it explains both profiling and the monitor fix. Julia Harper mtuxn!mtung!jdh 0707070000020033231006440001460001440000010232210367445445000001300000000000TRAILER!!!reated when the program exits that has counts and times for each subroutine. The information in this file (mon.out) can be easily examined by running the program prof(1); monitor(3) can also be called by a user. It can be used to keep track of certain parts of a program. The fix to monitor was to change its call to profile(2). profile(2) tells the operating system the granularity of time counting. That is, the operating system maps the address of the current position of a program into an array at every clock tick. The mapping can be as small as a one to one count, or many bytes can be mapped to one byte in the array. One argument to profile is a mask that tells the operating what the granularity of mapping should be. In Version 3.0, profil(2) needs a 32 bit mask. However, monitor(3) uses a 16 bit mask in its call to profil(2). The fix is to change the mask into a 32 bit mask. In order to use this new monitor(3), you must compile with a new library, libmon.a, which is what the MONITOR install gives you. By the way, the man page for profile(2) is wrong. It incorrectly says to use a 16 bit mask. The man page for monitor(3) is also wrong. It incorrectly tells the user to use address 0x02 for the start of a program, when it should be 0x80002. The user is told this piece of information during the MONITOR installation procedure. The source I used is 3.0 source that we got from Freehold. I guess this explanation is a bit long winded, but I think it explains both profiling and the monitor fix. Julia Harper mtuxn!mtung!jdh 0707070000020033231006440001460001440000010232210367445445000001300000000000TRAILER!!!reated when the program exits that has counts and times for each subroutine. The information in this file (mon.out) can be easily e