Ένας από τους προγραμματιστές της Google στη λίστα αλληλογραφίας LLVM σχετικά με την ανάπτυξη μιας τυπικής βιβλιοθήκης C πολλαπλών πλατφορμών (Libc) ως μέρος του έργου LLVM. Για διάφορους λόγους, η Google δεν είναι ικανοποιημένη με το τρέχον libc (glibc, musl) και η εταιρεία βρίσκεται στο δρόμο για την ανάπτυξη μιας νέας εφαρμογής, η οποία προτείνεται να αναπτυχθεί ως μέρος του LLVM.
Οι εξελίξεις του LLVM χρησιμοποιήθηκαν πρόσφατα ως βάση για την κατασκευή των εργαλείων συναρμολόγησης της Google. Η κύρια ιδέα είναι ότι εάν η Google έχει ήδη αρχίσει να αναπτύσσει το libc της, τότε γιατί να μην αναπτύξει αμέσως το σύστημά της ως μέρος του LLVM, το οποίο προσφέρει ήδη τη δική του τυπική βιβλιοθήκη για C++ (Libc++), αλλά δεν έχει παρόμοια τυπική βιβλιοθήκη για το C (libc).
Η ανάπτυξη σχεδιάζεται να πραγματοποιηθεί σταδιακά, αυξάνοντας σταδιακά τη λειτουργικότητα. Οι πρώτες επιλογές προτείνεται να σχεδιαστούν ως στρώμα μεταξύ της εφαρμογής και του συστήματος Libc, από το οποίο θα δανειστούν χαρακτηριστικά που δεν έχουν ακόμη υλοποιηθεί. Αφού φτάσει σε ένα συγκεκριμένο επίπεδο λειτουργικότητας, το νέο Libc μπορεί να χρησιμοποιηθεί ως πλήρης αντικατάσταση του συστήματος Libc. Σκοπεύουμε να ξεκινήσουμε με υποστήριξη για αρχιτεκτονική x86-64, Linux και στατική σύνδεση (δυναμική φόρτωση, σύνδεση και πρόσθετες αρχιτεκτονικές θα υλοποιηθούν δευτερευόντως).
Το έργο βρίσκεται ακόμη στο αρχικό στάδιο ανάπτυξης, αλλά οι βασικοί στόχοι έχουν ήδη καθοριστεί:
- Δυνατότητα και ανάπτυξη σύμφωνα με τη φιλοσοφία της παράδοσης μιας κοκκώδους βιβλιοθήκης και όχι ενός μονολιθικού συνόλου.
- Υποστήριξη για στατική σύνδεση σε λειτουργίες (εκτελέσιμα ανεξάρτητα από τη θέση) και χωρίς PIE. Παροχή CRT (Cruntime) και PIE loader για στατικά συνδεδεμένα εκτελέσιμα.
- Υποστήριξη για τις περισσότερες από τις τυπικές λειτουργίες της βιβλιοθήκης C, με προσθήκες POSIX και ορισμένες επεκτάσεις ειδικά για το σύστημα που απαιτούνται από υπάρχουσες εφαρμογές.
- Να είστε προσεκτικοί με τις επεκτάσεις για συγκεκριμένους προμηθευτές και να τις προσθέτετε μόνο όταν είναι απαραίτητο. Όσον αφορά την υποστήριξη για επεκτάσεις τρίτων, προτείνεται η χρήση της προσέγγισης των έργων Clang και libc++.
- Χρήση βέλτιστων πρακτικών στην ανάπτυξη με χρήση της εργαλειοθήκης LLVM, όπως η χρήση απολυμαντικού και δοκιμών fuzz από την αρχή.
Ένας από τους ενεργούς προγραμματιστές LLVM Είναι σαφές ότι είναι λογικό να αποστέλλεται το libc ως μέρος της εργαλειοθήκης LLVM, αλλά συνήθως, όταν προκύπτει τέτοια ανάγκη, χρησιμοποιούν τη βιβλιοθήκη musl, η οποία είναι καλογραμμένη, υποστηρίζει διάφορες αρχιτεκτονικές και παρέχει την απαραίτητη λειτουργικότητα, συμπεριλαμβανομένης της υποστήριξης για δυναμική σύνδεση. Μπορεί να δικαιολογείται η ενσωμάτωση του musl στο LLVM και η ανάπτυξη του ως πιρούνι συγχρονισμένο με το κύριο έργο.
Η γνώμη σας επίσης Ο συγγραφέας του έργου Musl, ο οποίος προσπάθησε να υποστηρίξει γιατί η πρόταση της Google και η συμπερίληψη του Libc στη διανομή LLVM είναι πολύ κακές ιδέες:
- Η ανάπτυξη και η διατήρηση ενός σωστού, συμβατού και υψηλής ποιότητας Libc είναι ένα πολύ δύσκολο έργο. Το πρόβλημα δεν είναι στην ποσότητα του κώδικα, αλλά στη διασφάλιση της σωστής συμπεριφοράς και των δυσκολιών στην υλοποίηση διεπαφών, λαμβάνοντας υπόψη το τεράστιο επίπεδο εφαρμογών που έχουν γραφτεί ποτέ σε C/C++, καθώς και εφαρμογές σε άλλες γλώσσες, ο χρόνος εκτέλεσης των οποίων χρησιμοποιείται από το Libc. Μια κατά μέτωπο προσέγγιση χωρίς να ληφθούν υπόψη οι αποχρώσεις θα οδηγήσει μόνο στο γεγονός ότι πολλά υπάρχοντα προγράμματα δεν θα μπορούν να λειτουργήσουν με το Libc, αλλά τότε ένα τέτοιο έργο δεν θα ενδιαφέρει τους καταναλωτές.
- Η εταιρική ανάπτυξη μπορεί να καταστρέψει το Libc, αλλά να το ωθήσει για ευρεία χρήση, με αποτέλεσμα την ανάγκη προσθήκης hacks για να διασφαλιστεί η συμβατότητα στις εφαρμογές. Η ανάπτυξη υπό την αιγίδα ενός εταιρικού έργου ανοιχτού κώδικα θα τραβήξει την κουβέρτα προς τις ανάγκες και τις λύσεις της εταιρείας, εις βάρος των συμφερόντων της κοινότητας. Για παράδειγμα, εάν εντοπίσετε ένα πρόβλημα που προκαλείται από ένα σφάλμα σε άλλο πρόγραμμα, στην ελεγχόμενη ανάπτυξη είναι ευκολότερο να διασφαλίσετε ότι το Libc είναι συμβατό με αυτό το σφάλμα παρά να διορθώσετε το ίδιο το σφάλμα. Η Apple χρησιμοποιεί το πιρούνι libc BSD για αυτούς τους σκοπούς και η Google χρησιμοποιεί το πιρούνι musl στη Φούξια. Η εμπειρία του προγραμματιστή του musl είναι ότι επικοινώνησαν κυρίως δικηγόροι για να διευκρινίσουν ζητήματα αδειοδότησης, αλλά ποτέ δεν επικοινώνησαν μαζί του για να διευκρινιστούν τεχνικές λεπτομέρειες προτού κάνει άχρηστες και ενοχλητικές αλλαγές στα υποκαταστήματά του.
- Η απουσία μονοκαλλιέργειας στην ανάπτυξη libc και εστίαση σε πρότυπα που βασίζονται στη συναίνεση και όχι σε ατομικό έλεγχο, που παρακινεί τους προγραμματιστές εφαρμογών να χρησιμοποιούν πρότυπα αντί να συνδέονται με συγκεκριμένες υλοποιήσεις. Αυτός είναι ο λόγος για τον οποίο ο συγγραφέας του musl είναι κατά της συμπερίληψης της βιβλιοθήκης του στο LLVM, καθώς και κατά της ανάπτυξης του libc εντός του LLVM, καθώς σε αυτήν την περίπτωση η ανεξάρτητη φύση του libc χάνεται και μια συγκεκριμένη υλοποίηση γίνεται μια πρώτης τάξεως λύση για Το LLVM και όλα τα άλλα γίνονται μια λύση δεύτερης κατηγορίας.
Πηγή: opennet.ru