הבדלים בין קלנג ו-LLVM לעומת GCC

כשמסתכלים על עולם המהדרים המודרניים, השמות קלאנג ו-LLVM הם מופיעים בכל מקום ולעתים קרובות משמשים לסירוגין. עם זאת, מאחורי ראשי התיבות הללו מסתתרים מושגים שונים שכדאי להבין, במיוחד אם אתם רוצים להפיק את המרב מהמערכת שלכם, מהפצת לינוקס שלכם, או מפרויקטי C, C++ או Objective-C שלכם.

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

הדבר הראשון שצריך להבהיר הוא ש LLVM אינו קומפיילר יחידLLVM אינו רק כלי או ספריית קומפילציה המשמשת כבסיס למגוון רחב של מערכות קדמיות, כולל Clang. בין היתר, LLVM כוללת אופטימיזצי קוד ביניים, מערכות קדמיות ליצירת קוד מכונה עבור ארכיטקטורות רבות, ותחליפים לכלים קלאסיים כמו... ar, nm, ranlib או אפילו קישורים כמו חברה.

קלאנג, מצידה, הוא ה- חזית של שפות C, C++ ו-Objective-C, Objective-C++, CUDA ו-RenderScript בתוך המערכת האקולוגית של LLVM. תפקידה העיקרי הוא לנתח את קוד המקור, לבדוק שהוא עומד בתקן השפה, לייצר אבחונים ברורים ולתרגם אותו לייצוג ביניים (IR) של LLVM, אשר לאחר מכן יעבור אופטימיזציה ויהפוך לקוד בר ביצוע על ידי שאר שרשרת הכלים.

לכן, כאשר אנשים מדברים על "שימוש בקלאנג" במערכת, הם למעשה משתמשים Clang כקומפיילר חזיתי ו-LLVM כקבצי קצה אחורייםעם אפשרות להסתמך גם על כלי השירות המשלימים של LLVM (binutils, linker, ספריות זמן ריצה וכו'). ניתן, לדוגמה, להשתמש ב-Clang כתחליף ישיר ל-GCC, אך להמשיך להשתמש בספריית ++C הסטנדרטית של GCC, בזמני הריצה שלה, ובכלל, בחלק ניכר מתשתית GNU.

נקודה חשובה אחת היא שבמערכות לינוקס רבות, רכיבי GCC (ספריית C++ סטנדרטית, unwinder, OpenMP, ספריות sanitizer וכו') עדיין... אבני הבניין הבסיסיות של המערכתלמרות זאת, האפשרות לבנות שרשרת כלים המבוססת כמעט לחלוטין על LLVM התבססה בהדרגה, ואף החליפה חלק גדול מה-binutils של GNU, והותירה רק את ספריית C הקלאסית כרכיב כמעט בלתי נמנע, שבדרך כלל... glibc.

הקשר בין קלנג, LLVM ו-GCC

לאחר שתפקידם של כל אחד מהם מובן, חשוב להבין כיצד Clang/LLVM ו-GCC משתווים כשרשראות כלים שלמות. שני הפרויקטים שואפים למטרה דומה: קומפיל קוד יעיל ונכון עבור מספר רב של ארכיטקטורות ופלטפורמות, אך הן עושות זאת עם עיצובים פנימיים שונים ועם החלטות שונות בנוגע לערכי ברירת מחדל והרחבות שפה.

אחת המטרות המוצהרות של פרויקט קלאנג היא לשמור על תאימות גבוהה עם קוד שתוכנן עבור GCCבפועל, משמעות הדבר היא שבהפצות רבות כמו Gentoo, ניתן לנסות להשתמש ב-Clang כמהדר ברירת המחדל עבור חלק גדול מחבילות המערכת. עם זאת, רעיון זה של "שימוש ב-Clang בכל המערכת" עדיין נחשב ניסיוני במקצת: חלק מהחבילות תלויות בהרחבות GCC ספציפיות מאוד, אחרות מניחות התנהגויות מסוימות מאפשרויות ברירת המחדל של GCC, וחלקן, למרות שהן מבצעות קומפילציה, סובלות מבעיות בזמן ריצה.

כאשר נכפה שימוש גלובלי בקלאנג ומשהו נשבר, הפתרון הקלאסי הוא בדרך כלל להגדיר סביבה של גיבוי באמצעות GCCבהקשר זה, GCC משמש עבור חבילות שאינן פועלות היטב עם Clang או עם הספריות וזמני הריצה האלטרנטיביים המסופקים על ידי LLVM. גישה מעורבת זו, נפוצה מאוד ב-Gentoo, מיושמת באמצעות תצורות ב- /etc/portage/make.conf וקבצי סביבה ספציפיים לכל קומפיילר.

היבט נוסף שבו הם שונים באופן משמעותי הוא באופן שבו הם מיישמים את אופטימיזציה של זמן קישור (LTO)Clang/LLVM פיתחו גישה משלהם, כאשר ThinLTO הוא המצב המומלץ, בעוד ש-GCC משתמש בעיצוב שונה עבור שלבי ה-LTO שלו. בפועל, משמעות הדבר היא שההתנהגות, הביצועים וכשלים פוטנציאליים עם LTO יכולים להשתנות באופן משמעותי בהתאם למהדר בו נעשה שימוש.

הבדלים עיקריים בהשוואה ל-GCC

בין ההבדלים הבולטים ביותר המשפיעים על השימוש היומיומי הם הרחבות השפה שכל מהדר תומך בהן. Clang שואף להיות תואם לחלק גדול ממערכת האקולוגית של GCC, אך הוא אינו תומך בהרחבות ספציפיות ל-GCC מסוימות, כגון פונקציות מקוננות. זוהי בפרט אחת הסיבות לכך ש-Clang התקשתה לקמפל חבילות קריטיות כמו sys-libs/glibcעם זאת, עבודה מתבצעת כדי להפוך את glibc לתואם יותר לכלים חלופיים.

ישנם גם הבדלים בדגלים הקשורים לטיפול בפעולות נקודה צפה. GCC פעיל כברירת מחדל. -ftrapping-math, בעוד שקלאנג משתמש כברירת מחדל -fno-trapping-mathסטייה זו מרמזת על כך שההתנהגות כלפי חריגים מסוימים של נקודה צפה יכולה להשתנות בין מהדרים שונים אם המפתח אינו מגדיר במפורש כיצד הוא רוצה שמקרים אלה יטופלו בפרויקט שלו.

נקודה מרכזית נוספת היא כיצד הם מטפלים באינטרפוזיציה סמנטית. GCC מאפשר זאת כברירת מחדל. -fsemantic-interpositionזה מאפשר הצבת סמלים בין ספריות משותפות בהתאם לכללי קישור ELF, אך זה יכול להגביל כמה אופטימיזציות בין-פרוצדוריות. Clang, לעומת זאת, מבצע אופטימיזציה בין-פונקציונלית כברירת מחדל ומציע את האפשרות -fno-semantic-interposition כדי לנצל עוד יותר את האופטימיזציות הללו כאשר הקוד מאפשר זאת ואינו מבוסס על אינטרפוזיציה קלאסית.

הבדלי העיצוב הללו אולי נראים עדינים, אך יש להם השפעה של ממש על האופן שבו תוכנה מתקמפלת ומתנהגת. מקובל שמה ש"עובד בצורה מושלמת" עם GCC דורש... התאמות בדגלים או בקוד המקור לקמפל ולרוץ נכון עם Clang ולהיפך, במיוחד בפרויקטים שדוחפים את גבולות התקן או תלויים בפרטים עדינים מאוד של הקישור.

הבדלים מינוריים אך רלוונטיים

ברמת אפשרויות הבנייה המוגדרות כברירת מחדל, ישנם גם ניואנסים פחות ברורים שכדאי להכיר. לדוגמה, GCC משתמש באפשרות כברירת מחדל. -ffp-contract=fast, בעוד ש-Clang מקבל את ערך ברירת המחדל -ffp-contract=onהתצורה של GCC היא מעט אגרסיבית יותר ויכולה לסדר מחדש או לבצע אופטימיזציה בדרכים שבתרחישים מסוימים רגישים מבחינה מספרית, הן מעט מסוכנות יותר. Clang, עם הגדרות ברירת המחדל שלו, נוטה להיות שמרנית יותר, התנהגות שרבים רואים בה בטוחה יותר אלא אם כן המטרה היא במפורש למקסם את הביצועים.

בנוגע לווקטוריזציה, עד גרסה 12, GCC לא ביצע אופטימיזציות וקטוריות ברמה -O2 או נמוך יותרקלאנג, לעומת זאת, מפעיל אופטימיזציות וקטוריות בכל הרמות מעל -O1, למעט ב -Ozכאשר זה מוגבל לווקטורייזר SLP. למרות שזה לעיתים רחוקות גורם לבעיות ישירות, זה מסביר מדוע לפעמים אותו קוד מקבל תפוקות שונות בהתאם למהדראפילו עם דגלי אופטימיזציה שנראים שווים לכאורה.

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

יתר על כן, ישנם פרטים פרקטיים קטנים, כמו העובדה ש-Clang, באינטגרציה שלו עם הפצות מסוימות, אין להתקין ישירות על /usr/binאבל בנתיבים ספציפיים שנוספים למשתנה הסביבה PATHזה משפיע על כלים כמו sudo, שמשתמשים ב- PATH הוא עצמו "טווח" ומקומפל לקובץ בינארי, כך שכאשר גרסה חדשה של Clang תופיע, ייתכן שהיא לא תהיה זמינה מ- sudo עד שכלי ההרשאות עובר קומפילציה או תצורה מחדש.

התקנה ותצורה עם Clang/LLVM

בהפצות כמו ג'נטו, Clang ושאר רכיבי ה-LLVM נשלטים באמצעות השתמש בדגלים ומשתנים ספציפיים כגון LLVM_TARGETSהאחרון קובע עבור אילו ארכיטקטורות בנויים מערכות LLVM backend, דבר קריטי אם ברצונך לתמוך במעבדים או התקנים מרובים.

כדי להתקין את Clang, בדרך כלל משתמשים במנהל החבילות, וברגע שהוא נמצא במערכת, ניתן להגדיר אותו לפעול כמהדר הראשי עבור חבילות מסוימות או באופן גלובלי. ב-Gentoo, הדרך הטיפוסית להגדיר את Clang כמהדר ברירת המחדל היא לשנות את המשתנים. CC y CXX בתיק /etc/portage/make.conf, ומפנה אותם לקבצי ההפעלה של Clang ולמקבילתם ב-C++.

אסטרטגיה גמישה מאוד נוספת היא להשתמש בקבצי סביבה ב /etc/portage/envכאשר מוגדרים "פרופיל" מהדר המבוסס על Clang ואחר על GCC. זה מאפשר הקצאה של פרופילי מהדר דרך הקובץ. /etc/portage/package.env, מהדרים שונים לכל חבילהלדוגמה, השתמשו ב-Clang עבור רוב המערכת, אך כפו את GCC על חבילות בעייתיות או רגישות במיוחד.

ישנם פרטים היסטוריים שיש לקחת בחשבון. לפני גרסה 14.0.0, קלאנג לא הייתה לי אפשרות default-pie דומה לזה של GCCזה דרש הכללה ידנית -fPIC en CFLAGS y -pie en LDFLAGS כדי ליצור קבצי הרצה עם מיקום עצמאי. עם גרסאות מודרניות זה פושט, אבל אם אתם מגיעים מתצורות ישנות יותר, מומלץ לבדוק ולנקות הפניות מיושנות במשתני הדגלים.

בכל מקרה, גם אם תבנה מערכת המתמקדת מאוד ב-Clang ו-LLVM, עדיין תצטרך GCC עבור חבילות מסוימות כמו glibc או wine. הפצות מסוימות מתחזקות עוקבות אחר באגים שמקמפלות את כל החבילות שנכשלות בקמפל עם Clang, ועוזרות להחליט מתי לפנות למהדר של GNU.

סביבות גיבוי ובחירת מהדר

בעת שימוש בפרופילים ניסיוניים המתמקדים ב-LLVM (לא זהה להתקנת Clang בלבד), מתעוררות מגבלות בסביבות גיבוי. סביבת "GCC fallback" טיפוסית עשויה לא לעבוד כפי שהיא אם כל המחסנית מוגדרת לשימוש, לדוגמה, libc++ כספריית C++ סטנדרטיתבמקרים אלה, דגלים כגון -stdlib=libc++ כאשר GCC מופעל בסביבת חירום זו, וגם אז ההתנהגות עשויה שלא להיות כצפוי.

הרעיון המעשי הוא ליצור ב /etc/portage/env קובץ תצורה, לדוגמה compiler-gcc, ומגדירים את משתני הסביבה הדרושים לקימפול עם GCC. לאחר מכן, ב /etc/portage/package.envהחבילות שחייבות להשתמש בסביבה זו מוקצות. דפוס זה חוזר על עצמו עם צירופים שונים: קלאנג ללא LTO, קלאנג עם LTO, GCC ללא LTO, GCC עם LTO וכו'.

לכן, כאשר חבילה נכשלת עם Clang (עקב הרחבות GCC, בעיות LTO, תלות צולבת וכו'), מספיק ל... הוסף אותו לרשימת החבילות שעברו קומפילציה עם סביבה אחרתזה הופך את הדו-קיום של Clang ו-GCC לניתן לניהול למדי, בתנאי שאתה ממושמע בתחזוקת קבצי התצורה הללו.

ברמה "אנושית" יותר, משתמשים רבים תוהים איזה מהדר יבחר סקריפט תצורה כאשר שניהם מותקנים. בדרך כלל, מערכת הבנייה פועלת לפי כללים ברורים: היא בוחנת משתני סביבה כגון CC y CXXבדוק אילו מהדרים זמינים ב- PATHובמקרים מסוימים נותנת עדיפות לשמות ספציפיים כגון gcc o clangלכן, ה"העדפה" אינה קסומה: היא נקבעת על ידי תצורת המערכת והפרמטרים שהוגדרו על ידי המשתמש.

שימוש מתקדם ב-Clang/LLVM: LTO, PGO ועוד

קלאנג משתלב מצוין עם טכניקות אופטימיזציה מתקדמות כגון LTO (אופטימיזציית זמן קישור) ו-PGO (אופטימיזציה מונחית פרופיל). במקרה של LTO, המהדר מייצר קוד ביטים של LLVM במקום קוד אובייקט מסורתי ודוחה את רוב האופטימיזציות לשלב הקישור.

קלאנג תומך בשני סוגים עיקריים של LTO. מצד אחד, ה- LTO הושלםאשר מנתחת את יחידת הקישורים כולה בבת אחת; זוהי הגישה הקלאסית, בדומה ל-GCC, אך כיום היא כבר לא מומלצת כאפשרות ראשונה. מצד שני, יש ThinLTOכאשר יחידת הקישור נסרקת ומחולקת לחלקים מרובים. כל חלק מכיל רק את הקוד הרלוונטי להיקפו, מה שמפחית את צריכת הזיכרון, מאיץ את הקומפילציה ומגדיל את המקבילות מבלי להתפשר על ביצועים רבים מדי.

בפועל, כדי להפעיל את ThinLTO משתמשים בדגל כגון -flto=thin במשתני הקומפילציה. אם ברצונך להשתמש ב-LTO המלא, פשוט החלף אותו ב- -fltoללא הבדלי תאימות משמעותיים בין שני המצבים. עם זאת, כדאי לזכור שאם החבילה clang-common הוא לא נבנה עם דגל USE default-lld, יהיה צורך להוסיף -fuse-ld=lld a LDFLAGS כך שנעשה שימוש במקשר LLVM.

ניתן גם להשתמש בכלי binutils של LLVM, כגון llvm-ar, llvm-nm y llvm-ranlibבמיוחד כשעובדים עם קוד ביטים שנוצר על ידי LTO. אלו הן חלופות שתוכננו במיוחד כדי להבין את הפורמט הזה, אם כי הניסיון המעשי משתנה בהתאם לפרויקט והן לא תמיד מציעות שיפורים ברורים לעומת כלים סטנדרטיים.

בנוגע ל-PGO, המערכת האקולוגית של LLVM מספקת רכיבים כגון clang-runtime עם דגל USE sanitize y compiler-rt-sanitizers עם דגלים כמו profile u orcהפעלת דגל USE pgo ברמה הגלובלית או ברמה החבילה, ניתן לאסוף מידע על ביצוע תוכניות בזמן אמת ולהזין אותו למהדר באמצעות פרופילים אלה, כך שיוכל לייעל את נתיבי הקוד החם בהתבסס על שימוש בפועל.

בנוסף לאמור לעיל, קלאנג עובד מצוין עם מערכות מטמון כגון cacheלאחר התקנת Clang, פרויקטים אלה בדרך כלל פועלים כמעט באופן אוטומטי, מה שמאיץ את תהליך ההרכבה מחדש. ובתחום המיוחד יותר, פרויקטים כמו מדחףPropeller היא גישת PGO שנועדה לטפל בבעיות בכלים כמו Bolt, ובמיוחד בצריכת זיכרון. Propeller מסתמך על Clang ודורש תלויות כגון... app-arch/zstd עם דגל USE static-libs, בנוסף לאוסף ממקור ספציפי למדי.

בעיות נפוצות וכיצד להתמודד איתן באמצעות קלאנג

בסביבות שבהן Clang משמש כקומפיילר הראשי, השגיאות הנפוצות ביותר נוטות להתקבץ לכמה דפוסים אופייניים. דוגמה ראשונה ברורה היא שגיאות קומפילציה בעת שימוש ב-LTOאם חבילה עוברת קומפילציה עם -flto ואם מופיעות שגיאות חוזרות ביומני ה-Portage, פתרון מעשי הוא להשבית LTO עבור חבילה ספציפית זו באמצעות סביבה כמו compiler-clang בלי LTO.

לפעמים, אפילו אם LTO מושבת בחבילה הכושלת, הבעיה נמשכת מכיוון ספרייה תלויה נוספת הורכבה באמצעות LTO והיא אינה פועלת כראוידוגמה קלאסית היא כאשר חבילה כמו boehm-gc זה מתפוצץ בגלל התלות שלו libatomic_ops הוא עובר קומפילציה עם LTO ומייצר התנהגות בלתי צפויה. במקרים אלה, יש לבנות מחדש את התלות ללא LTO, ויש לוודא ששתי החבילות עוברות קומפילציה עם סביבה עקבית.

סוג נפוץ נוסף של בעיה מתרחש כאשר קוד המקור משתמש הרחבות GNU מבלי לציין את התקן הנכון דרך הדגל -std=GCC בדרך כלל מאפשר רבים מהשימושים הללו מבלי לדרוש תקן ספציפי, בעוד ש-Clang מבטל חלק מההרחבות הנדירות יותר אלא אם כן צוין אחרת במפורש. אם חבילה תלויה בהרחבות אלו, יש לקמפל אותה עם דגלים כגון -std=gnu89, -std=gnu99 o -std=gnu++98, בהתאם לשפה ולסטנדרט הצפוי.

תסמין אופייני לבעיה זו הוא ראיית הגדרות מרובות של פונקציות מוטבעות ביומני הקומפילציה. הסיבה לכך היא ש-Clang, כברירת מחדל, משתמש בכללי C99 מוטבעים, שאינם משתלבים היטב עם קוד שתוכנן עבור gnu89בתרחיש זה, כפייה -std=gnu89 זה בדרך כלל מספיק; אם לא, תמיד ישנה אפשרות לקמפל את החבילה המתנגשת עם GCC באמצעות אחת מסביבות הגיבוי.

ספקות נראים לעתים קרובות גם כאשר המערכת מצביעה על שגיאות כגון sudo: clang: command not foundמה שקורה שם הוא שקלאנג הותקן בנתיב שנוסף ל- PATH מהמשתמש, אבל sudo שומר על נתיב פנימי משלוהנתיב שהוגדר במהלך תהליך הקומפילציה הבינארית לא יכלול את נתיב ה-Clang עד ש-sudo יבוצע קומפילציה מחדש או עד שהגדרותיו יותאמו. לכן, sudo לא ימצא את Clang, למרות שמשתמש רגיל יכול להריץ אותו ללא בעיות.

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

אם משווים את כל החלקים האלה, אפשר לראות שהטנדם קלאנג + LLVM היא מציעה מערכת אקולוגית חזקה, גמישה ומודרנית מאוד, אך כזו שעדיין מתקיימת בדו-קשור עם GCC במערכות רבות, במיוחד ברמות רגישות כמו ספריית C או חבילות ישנות מאוד. הבנת ההבדלים ביניהם, כיצד הם משלימים זה את זה, ואילו התאמות נדרשות בדגלים, LTOs או תקני שפה הופכת את המעבר ביניהם לפחות לקפיצה אל הלא נודע ויותר לכלי בעל ערך בעת הגדרת סביבת הפיתוח או מערכת לינוקס מותאמת אישית.