עבודה ב-T2 מבוא לתכנות מערכות

מה נראה היום? נלמד עבודה בסיסית בטרמינל. נלמד כיצד לכתוב תוכנית ב-Eclipse. נכיר כלים שימושיים ל-Debugging. מבוא לתכנות מערכות

התכנית נכתוב תכנית שמנהלת חשבונות בנק מקבלת כפרמטר קובץ שמכיל את נתוני הלקוחות מחכה לפקודות מהמשתמש בסיום הריצה שומרת את נתוני הלקוחות בקובץ פלט שמתקבל כפרמטר מבוא לתכנות מערכות

התכנית database.txt [Business Yaron Levi 6000.00] [Regular Dani Din 600.00] myuser@t2 > bank database.txt database2.txt add Moshe Cohen Premium 50000.00 deposit Moshe Cohen Premium 4000.00 withdraw Dani Din Regular 300.00 exit myuser@t2 > database2.txt [Business Yaron Levi 6000.00] [Regular Dani Din 300.00] [Premium Moshe Cohen 54000.00] מבוא לתכנות מערכות

התכנית התכנית תורכב משני מודולים: מודול לניהול חשבונות יורכב מהקבצים account.c, account.h מודול לקליטת פקודות מהמשתמש יורכב מהקובץ main.c מבוא לתכנות מערכות

שלב 1: התחברות ל-T2 נשתמש ב-SSH כדי להתחבר ל-T2. קדימה לעבודה... SSH ניתנת להורדה עבור Windows מהכתובת: ftp://ftp.cs.technion.ac.il/pub/ssh-client/sshclient.exe עבור לינוקס (או OSX) ניתן פשוט לפתוח חלון טרמינל ולהשתמש בפקודה “ssh”. קדימה לעבודה... מבוא לתכנות מערכות

שלב 1: התחברות ל-T2 ניצור את מבנה התיקיות הבא תחת תיקית הבית: mtm aux_tut מבוא לתכנות מערכות

שלב 2: קידוד ישנם מספר עורכי טקסט על ה-T2: nano Emacs נראה בהמשך... עורך טקסט מתקדם מומלץ לנסות קראו עליו בשקפי הסדנאות המקוריים שבאתר הקורס זה בסה"כ כמה שקפים... מבוא לתכנות מערכות

שלב 2: קידוד כעת נוותר על הקידוד ונעתיק את קבצי התכנית מהתיקייה ~mtm/public/1314b/aux_tut/bank אמורה להווצר לנו תיקיית bank תחת aux_tut מבוא לתכנות מערכות

שלב 3: קומפילציה לאחר כתיבת הקוד, אנו רוצים להריץ את התכנית. לפני כן, יש לקמפל את הקוד. ברוב מערכות ה-Unix מותקן קומפיילר C הקרוי GCC. קיצור עבור GNU Compiler Collection. לא להתבלבל בין קומפיילר לסביבת פיתוח (IDE). הקומפיילר הוא תכנית שממירה קבצי קוד (למשל ב-C) לקובץ המכיל קוד אסמבלי, אותו ניתן להריץ. סביבת פיתוח מכילה קומפיילר, דיבאגר ועוד כלים נוספים. בהמסך הסמסטר נעבור לתכנות בשפת ++C. GCC מסוגל להדר גם את שפה זו אך במקרים אלו נשתמש בפקודה g++ כדי לקמפל את הקוד. GNU Compiler Collection - מקור השם הוא בגלל ש-GCC מכיל קומפיילרים גם לשפות נוספות (בפרט לשפת ++C כמו שהוזכר לעיל). מבוא לתכנות מערכות

שלב 3: קומפילציה נריץ את הקומפיילר עם קבצי הקוד כפרמטרים. התקבל קובץ ההרצה a.out. דומה לקובץ EXE של Windows. אין צורך להוסיף הרשאות ריצה לקובץ זה מאחר והדבר נעשה אוטומטית ע"י GCC. מבוא לתכנות מערכות

דגלים של GCC בקורס זה נקמפל את התכניות שלנו עם שורת הפקודה הבאה: -o <exefile>מורה לקומפיילר לכתוב את קובץ הפלט לקובץ ששמו exefile במקום לברירת המחדל a.out. -std=c99 קובע את סטנדרט השפה לפיו הקומפיילר יעבוד. הסטדרנט בקורס הוא C99. ב-C99 ניתן להגדיר משתנים לא רק בתחילת בלוק, ואף בתחילת לולאת for: -pedantic-errors מכריח את הקומפיילר להקפיד על הסטנדרט הנבחר ולפלוט שגיאות על הפרות שלו. myuser@t2 > gcc -o <exefile> -std=c99 -pedantic-errors -Wall -Werror <.c files> for (int i = 0; i < n; ++i) { printf("%d\n", i); } מבוא לתכנות מערכות

דגלים של GCC בקורס זה נקמפל את התכניות שלנו עם שורת הפקודה הבאה: -Wall גורם לקומפיילר להציג את כל האזהרות בזמן קומפילציה. אזהרות קומפילציה דומות לשגיאות. שגיאות (errors) מפסיקות את הקומפילציה, בעוד אזהרות (warnings) לא. בד"כ מצביעות על טעויות מתכנת או על קוד שנכתב בצורה לא טובה. נעדיף לראות את אזהרות אלו ולחסוך לנו טעויות בהמשך. -Werror מורה לקומפיילר להתייחס לאזהרה כאל שגיאה. כלומר הקוד שלכם בקורס חייב להתקמפל גם ללא אזהרות. בד"כ (ובקורס הזה תמיד) אין סיבה שהקוד שלכם יכיל אזהרות. myuser@t2 > gcc -o <exefile> -std=c99 -pedantic-errors -Wall -Werror <.c files> מומלץ להשתמש בדגלים אלו תמיד. בפרט בדגלי -Wall ו--std=c99 שלהם תרומה רבה ביצירת קוד קריא יותר והגנה על המתכנת מבזבוז זמן עבור שגיאות טפשיות. מבוא לתכנות מערכות

שלב 3: קומפילציה כעת נקמפל את התכנית מחדש בעזרת כל הדגלים הדרושים. נחזיק אצבעות שלא נקבל אזהרות מהקומפיילר... מבוא לתכנות מערכות

שלב 4: הרצת ובדיקת התכנית כעת נרצה לבדוק האם התכנית שלנו נכונה: נריץ את התכנית עם קובץ נתונים מוכן מראש. נכניס מספר פקודות לתכנית. נוודא שקובץ הפלט זהה למה שאנו מצפים. זוהי השיטה הידנית, והיא אינה יעילה כאשר מבצעים שינוי קטן בקוד. למה הכנסת קלט ידנית היא רעיון רע? כי הקלט לתכנית יוכנס יותר מפעם אחת תמיד. וכל הכנסה היא פעולה שלוקחת הרבה זמן. לכן נעדיף לשמור את הקלט בקובץ ופשוט להשתמש בו. בצורה זו גם לא נשכח לבדוק את הקוד כנגד באגים פשוטים שיצוצו בהפתעה בהמשך. בנוסף, הרצה אוטומטית של בדיקות מעודדת בדיקה רציפה של הקוד ותחסוך *שעות* לסטודנט הממוצע אם ישתמש בשיטה זו. מאפיינים של בדיקות טובות: קצרות בודקות תרחיש ספציפי. במקרה של כשלון קל להבין את הטעות שגרמה לו. בקיצור - המנעו מקבצי בדיקה ענקיים שנוצרו בצורה אוטומטית, או לפחות השתמשו בהם רק בנוסף לקבצי בדיקות קצרים וממוקדים. מבוא לתכנות מערכות

שלב 4: הרצת ובדיקת התכנית נרצה לפתח שיטה אוטומטית לבדיקת התכנית: נכתוב קבצי קלט וקובץ פלט צפוי. נריץ את התכנית עם קבצי הקלט. נבדוק בצורה אוטומטית האם קובץ הפלט זהה לקובץ הפלט הצפוי. שיטה זו חוסכת הכנסת קלט ידנית לתכנית בשלב הבדיקה. איך עושים את זה?! מבוא לתכנות מערכות

השוואת טקסט: diff הפקודה diff משמשת להשוואת שני קבצי טקסט. בדוגמה: אם הקבצים זהים לא יודפס כלום. אם הם שונים יודפסו השינויים שיש לבצע על הקובץ הראשון כדי להפכו לשני. myuser@t2 > cat file1.txt [Business Yaron Levi 6000.00] [Regular Dani Din 600.00] myuser@t2 > cat file2.txt [Premium Moshe Cohen 54000.00] [Regular Dani Din 300.00] myuser@t2 > diff file1.txt file2.txt 0a1 > [Premium Moshe Cohen 54000.00] 2c3 < [Regular Dani Din 600.00] --- > [Regular Dani Din 300.00] בדוגמה: 0a1: בשורה 0 (לפני השורה הראשונה) יש להוסיף את שורה 1 (מהקובץ השני) :2c3 את שורה 2 יש להחליף בשורה 3 מהקובץ השני. אכן, הפלט אינו נוח לקריאה. השימוש העיקרי לפקודת diff שדווקא לא יתורגל בקורס הוא בהשוואת חלקי קוד. פקודה זו מאפשרת בצורה נוחה למתכנת לראות אילו שינויים הוכנסו בקובץ ולמצוא בקלות הבדלי גרסאות. מבוא לתכנות מערכות

השוואת טקסט: diff אם יש פלט – הקבצים שונים! אם אין פלט – הקבצים זהים! פקודה זו מאפשרת בצורה נוחה למתכנת לראות אילו שינויים הוכנסו בקובץ ולמצוא בקלות הבדלי גרסאות. מבוא לתכנות מערכות

השוואת טקסט: sdiff sdiff מאפשרת צורה נוחה יותר להבנת ההבדלים בין קבצים כאשר הם אכן קיימים. shiroko2@t2 > diff file1.txt file2.txt > [Premium Moshe Cohen 54000.00] [Business Yaron Levi 6000.00] [Business Yaron Levi 6000.00] [Regular Dani Din 600.00] | [Regular Dani Din 300.00] כאשר הקבצים זהים, פקודה זו פחות נוחה מאחר והיא מדפיסה את שני הקבצים למסך תמיד (גם שורות זהות). לכן מומלץ להשתמש בה כאשר הפלט של diff אינו נוח להבנה (בד"כ כל מקרה שבו diff לא מחזירה פלט ריק) כאשר עובדים במנשק גרפי יש כלים נוחים עוד יותר לביצוע השוואות אלו. - ניתן לנסות את הפקודה kompare ב-T2. - ניתן להוריד את התוכנה WinMerge ל-Windows. - ב-Eclipse ניתן בתפריט האפשרויות עבור כל קובץ בפרויקט ניתן לבחור בתת התפריט Compare With ושם להשוות את הקובץ עם גרסאות קודמות או לבחור שני קבצים ולהשוות אותם אחד עם השני. מבוא לתכנות מערכות

שלב 4: הרצת ובדיקת התכנית נרצה לפתח שיטה אוטומטית לבדיקת התכנית: נכתוב קבצי קלט וקובץ פלט צפוי. נריץ את התכנית עם קבצי הקלט. נבדוק בעזרת diff האם קובץ הפלט זהה לקובץ הפלט הצפוי. מבוא לתכנות מערכות

שלב 4: הרצת ובדיקת התכנית נכתוב תרחישים קצרים הבודקים את התכנית קובץ נתונים התחלתי קובץ קלט לפקודות קובץ הפלט הצפוי למזלנו כבר כתבו עבורנו כמה כאלה, בתיקייה test. כדי לבדוק את התכנית נריץ את הפקודות הבאות: אם לא מודפס כלום התכנית עובדת כמתוכנן. אחרת ננתח את הפלט ונבדוק מהי ההתנהגות הלא נכונה. אפשר גם שהתכנית תתרסק ולא נגיע לפקודה השנייה. myuser@t2 > ./bank test/test1.data out.txt < test/test1.in myuser@t2 > diff out.txt test/test1.out מבוא לתכנות מערכות

תכונות ה-Shell ה-Shell היא הסביבה הטקסטואלית בה מורצות הפקודות בשימוש בטרמינל. בהתחברות ל-T2 מופעלת ה-Shell הקרויה Bash. כל Shell מכילה קיצורים ע"מ להקל על המשתמש. קיצורים בסיסיים המקלים על העבודה: TAB: משלים את המילה הנוכחית לשם קובץ או פקודה. ניתן להשתמש בחצים ↑/↓ כדי לעבור על הפקודות האחרונות שבוצעו. מבוא לתכנות מערכות

Scripts ניתן לכתוב מספר פקודות בקובץ טקסט ולהריץ אותן ע"י הפקודה source. קבצים אלו נקראים תסריטים (scripts). כרגע נכיר בצורה בסיסית, ובהמשך הקורס נעמיק בחומר. לדוגמה, ניתן לכתוב Script שמגבה את הקוד שלנו על השרת. השימוש בסביבת C-Shell ב-Unix וכתיבת תסריטים (scripts) יילמד בתרגולים 6-7 ובתרגלי בית מס' 3. הרצות script בצורה זו עובדות רק בסביבת Unix (קיים מנגנון דומה תחת Windows שאינו בחומר הקורס). מבוא לתכנות מערכות

שלב 5: בדיקות אוטומטיות אנו יודעים כיצד לבדוק את התכנית בצורה אוטומטית. אנו יודעים לכתוב תסריטים. נאחד את השיטות כדי לאפשר בדיקה אוטומטית משופרת. הקפידו על יצירת בדיקות ותסריט להרצתן כבר בתחילת העבודה הריצו לאחר כל שינוי בקוד הרצה קבועה של הבדיקות תמנע בזבוז זמן בבדיקות ו"פאדיחות" ברגע האחרון. run_tests.csh gcc -o bank -std=c99 -pedantic-errors -Wall -Werror main.c account.c echo “Test no.1 (Adding accounts)” ./bank test/test1.data out.txt < test/test1.in diff out.txt test/test1.out echo “Test no.2 (Depositing)” ./bank test/test2.data out.txt < test/test2.in diff out.txt test/test2.out echo Test no.3 (Withdraw) ./bank test/test3.data out.txt < test/test3.in diff out.txt test/test3.out myuser@t2 > source run_tests.csh Test no.1 (Adding accounts) Test no.2 (Depositing) Test no.3 (Withdraw) myuser@t2 > מבוא לתכנות מערכות

שלב 6: דיבוג כלי אחרון וחשוב לעבודה במנשק טקסט הוא GDB. GDB הוא דיבאגר בסיסי המגיע בד"כ עם GCC. "דיבאגר" מאפשר להריץ את התכנית שלנו בצורה מבוקרת ולבדוק את מצב התכנית. איתור נקודות התרסקות הדפסת ערכי משתנים כאשר מקמפלים את התכנית לצרכי "דיבוג" חשוב להוסיף את הדגל -g. עוזר ל-GDB לספק לנו מידע מקיף יותר. myuser@t2 > gcc -o bank -g -std=c99 -pedantic-errors -Wall -Werror main.c account.c מבוא לתכנות מערכות

GDB vs. Segmentation Fault #include <stdio.h>   int twice(int* ptr) { int result = *ptr + *ptr; return result; } int main() { int a = 5; printf("%d\n",twice(&a)); int* ptr = NULL; printf("%d\n",twice(ptr)); return 0; נביט בתכנית הנתונה משמאל הקוד נמצא בתיקייה ~mtm/public/1314b/aux_tut/crash מבוא לתכנות מערכות

GDB vs. Segmentation Fault #include <stdio.h>   int twice(int* ptr) { int result = *ptr + *ptr; return result; } int main() { int a = 5; printf("%d\n",twice(&a)); int* ptr = NULL; printf("%d\n",twice(ptr)); return 0; קריאת מצביע שערכו NULL תגרום לקריסת התכנית בתכנית הנתונה הקריאה השנייה ל-f תגרום לקריאת הערך ממצביע NULL. הרצה רגילה של התכנית ללא דיבאגר אינה מספקת מידע על הסיבה להתרסקות. myuser@t2 > gcc crash.c myuser@t2 > ./a.out 10 Segmentation fault myuser@t2 > מבוא לתכנות מערכות

GDB vs. Segmentation Fault GDB עובדת בעזרת מנשק טקסטואלי. כאשר התכנית הנבדקת אינה רצה תופיע שורת פקודה בה ניתן להכניס פקודות שונות של GDB, למשל: run - מריצה את התכנית continue - ממשיכה את ריצת התכנית לאחר הפסקה step מריץ שורת קוד אחת בדיוק (נכנס לפונקציה) print - מקבל שם משתנה או ביטוי כפרמטר ומדפיס את ערכו ניתן לעצור זמנית את ריצת התכנית ע"י Ctrl+z. ניתן להפסיק את ריצת התכנית לחלוטין ע"י Ctrl+C. myuser@t2 > gdb <binary file> מבוא לתכנות מערכות

GDB vs. Segmentation Fault הדגל -q חוסך הדפסה של הודעת הפתיחה. הפקודה run יכולה לקבל פרמטרים להרצת התכנית myuser@t2 > gcc -g crash.c myuser@t2 > gdb -q a.out (gdb) run Using host libthread_db library "/lib64/tls/libthread_db.so.1". Starting program: /u1/115/myuser/a.out 10 Program received signal SIGSEGV, Segmentation fault. 0x00000000004004b4 in twice (ptr=0x0) at crash.c:4 4 int result = *ptr + *ptr; (gdb) backtrace #0 0x00000000004004b4 in twice (ptr=0x0) at crash.c:4 #1 0x00000000004004fa in main () at crash.c:12 (gdb) ע"י backtrace ניתן להדפיס את מחסנית הקריאות. במקרה שלנו הפונקציה twice נקראת מ-main. מבוא לתכנות מערכות

Breakpoints חלק גדול מהבאגים הם שגיאות התנהגותיות של התכנית. כדי לבדוק אותן נרצה לעצור את התכנית, לבדוק את ערכי המשתנים ולהתקדם צעד צעד. כדי לעצור את התכנית בשורת קוד מסוימת נוסיף נקודת עצירה (breakpoint) ע"י הפקודה break ושם הפונקציה שיש לעצור בתחילתה נוכל לבדוק את ערכי המשתנים בעזרת הפקודה print. כדי להמשיך בריצת התכנית נשתמש ב-continue (המשך עד נקודת העצירה הבאה) כדי להתקדם בצורה מבוקרת נשתמש בפקודה step. מבוא לתכנות מערכות

GDB: סיכום העבודה עם GDB אינה פשוטה בהתחלה. עדיין עדיפה על עבודה ללא דיבאגר. התחילו בשימוש בפקודות הפשוטות שמוצגות כאן. ניתן לקבל את רשימת הפקודות המלאה ע"י הפקודה help ולקבל מידע מפורט יותר. מבוא לתכנות מערכות