Raspberry Pi में इस्तेमाल हुई ARM पीढ़ियों के इतिहास को देखें तो यह सचमुच चौंकाने वाली बात है कि चिप कितनी पुरानी थी
2014 में जब Raspberry Pi B+ आया, तब भी उसमें इस्तेमाल ARM1176 core 2003 का था, यानी वह पहले से ही 11 साल पुराना था
इसलिए किसी और प्लेटफ़ॉर्म, जैसे नए Raspberry Pi पर बिल्ड करते समय compatible code बनाने के लिए architecture flags साफ़-साफ़ बताने पड़ें, यह अजीब नहीं है
हालांकि अगर Raspberry Pi B+ पर ही बिल्ड करते समय भी सही architecture default में सेट नहीं हो रहा है, तो यह distro defaults की तरफ़ की configuration error जैसा लगता है
मुझे याद है कि असली Pi में TV box में इस्तेमाल होने के बाद बची हुई chip लगाई गई थी
ऐसे products में कीमत के कारण ज़रूरत से ज़्यादा compute performance डालना बहुत कम होता है
शुरुआत से ही इसे कम-कीमत computer के रूप में बनाना था
असल में B+ पर बिल्ड नहीं किया गया था
पोस्ट में लिखा है कि “काफी तेज़ Pi 4B build host से binary लेकर इस पुराने device पर चलाने की कोशिश की, तो illegal instruction आया”
यह कुछ वैसा ही है जैसे Windows 11 पर नए MSVC से build की गई .EXE को Windows XP वाले पुराने PC पर चलाने की कोशिश करना
शायद Pi 4B पर चलने वाला पूरा Pi distro भी B+ पर न चले, और kernel भी उसी तरह compile किया गया हो सकता है
लगता है कि पोस्ट या लेख में इसे साफ़ तौर पर नहीं बताया गया, लेकिन क्या यह bug नहीं है?
LLVM bugs में खोजा तो लगभग इसी issue जैसा एक item मिला, लेकिन वह 2012 का bug है और बंद हो चुका है। आख़िरी कुछ comments देखने पर लगा कि शायद वह असल में ठीक नहीं हुआ था, लेकिन मैंने बस सरसरी तौर पर देखा है, इसलिए संभव है कि मैं ग़लत समझा होऊँ https://github.com/llvm/llvm-project/issues/13989
दोबारा देखने पर पोस्ट के अंत में कहा गया था कि target को explicitly पास करने पर काम करने वाला program बनता है। तो यह किसी तरह का configuration bug लगता है, और Unix में मुझे लगता है कि default target current processor होना चाहिए, लेकिन पक्का नहीं हूँ
जिस bug को link किया है, वह शायद target सही तरह set करने के बाद भी गलत code बनाने की समस्या थी, और अच्छी बात है कि अभी स्थिति वैसी नहीं लगती
सही। link किया गया bug यह था कि compiler को armv6 target करने को कहा गया था, फिर भी वह armv7 instructions output कर रहा था
Rachel की समस्या compiler को armv6 target करने के लिए बताने से हल हो गई, इसलिए वह bug पहले ही ठीक हो चुका है और यह issue अलग लगता है
जाहिर है bug है, लेकिन लेखक ने report करने के बजाय थोड़ा clickbait जैसा title वाला blog post लिखा और “बहुत अजीब है” पर खत्म कर दिया, ऐसा लगता है
जिस database पर मैं काम करता हूँ, ClickHouse, वह बहुत पुराने hardware के साथ compatibility बनाए रखने के लिए काफ़ी कोशिश करता है
standard ARM binary 2016 के Armv8.2 की मांग करती है और Raspberry Pi 2 के बाद वाले models पर इस्तेमाल की जा सकती है। x86 binary लगभग 2010 के आसपास के ऐसे hardware पर चलती है जिसमें fast CRC के लिए SSE4.2 और pclmul* instructions हों
हम Armv8.0 और सिर्फ़ SSE2 वाले systems के लिए भी binaries build करते हैं, लेकिन उन्हें CI से test नहीं करते। fast install script target host के हिसाब से सही binary download करके unzip कर देती है backward compatibility और नई AArch64 generations की CPU features का उपयोग करने के बीच balance बनाना कुल मिलाकर मुश्किल लगता है https://en.wikipedia.org/wiki/AArch64
तंग budget वाले संस्थान, जैसे emerging countries की universities, या ऐसे hobby users जिनके पास hardware upgrade की क्षमता नहीं है, हैरान करने वाली संख्या में मिले
तकनीकी रूप से /proc/cpuinfo के CPU flags हमेशा compiler को दिए जाने वाले -march= flags से match नहीं करते, यह काफ़ी झंझट भरा था। जैसे "lrcpc" और "rcpc" अलग-अलग तरह से दिखते हैं
इसे ठीक से चलाने के लिए असल में दो तरह के flag sets maintain करने पड़ते हैं
ऐसे case में कई builds देना बेहतर लगता है ताकि customers अपने architecture के सबसे करीब वाला चुन सकें; इससे सबका फायदा होगा
समस्या शायद bookworm के मौजूदा clang-13 package में configured target बदलने की है
खास तौर पर, bullseye और clang-11 में default target armv6k-unknown-linux-gnueabihf है, जबकि bookworm और clang-13 में arm-unknown-linux-gnueabihf है
या फिर LLVM की तरफ़ उस build configuration का default बदल गया हो सकता है
लगता है यह जानबूझकर किया गया बदलाव नहीं होगा
आसपास की टिप्पणियों में जैसे /etc/env.d/gcc का ज़िक्र था, काफ़ी संभावना है कि यह environment से जानकारी पढ़ने के तरीके से जुड़ा हो
default triple शायद arm-unknown-linux जैसा कोई मान होगा, अगर clang को ज़्यादा specific जानकारी न मिले या पास न की जाए; लगता है ज़्यादा specific target बताने वाला mechanism टूट गया है
इसका मतलब यह हो सकता है कि ARMv6 buildbot नहीं है, या buildbot तो है लेकिन वहाँ implicit configuration अभी भी ठीक से काम कर रही है
LLVM सचमुच बहुत अच्छा cross compiler है। किसी भी target से किसी भी target के लिए बिना बड़े झंझट के build किया जा सकता है
Clang उतना आकर्षक नहीं है। अगर वह target support के साथ build हुआ है, और आप उसे ठीक से बता सकें कि किस target के लिए build करना है, तो शायद वह सही काम करेगा। इस लेख में भी अनुमान गलत था, लेकिन ज़्यादा जानकारी देने पर यह सही तरह काम करने लगा
runtime libraries की स्थिति और खराब है। भले ही आपने armv4 जैसे target के लिए build किया हो, आपको उसके मुताबिक libc आदि ढूँढनी होगी, और compiler को उन libraries और headers की location बतानी पड़ सकती है; इस हिस्से की details अभी भी साफ़ नहीं हैं
ज़्यादातर distributions और compilers ने कुछ साल पहले practically ARMv6 support छोड़ दिया था
पुराने Synology NAS के लिए binaries build करते समय मुझे भी ऐसी ही समस्या आई थी
Clang को /etc/env.d/gcc से जानकारी पढ़ने की ज़रूरत क्यों होनी चाहिए?
clang/clang++ /etc/env.d/gcc से target flags और profiles पढ़ते हैं, और इन्हें सही बनाए रखना operating system की ज़िम्मेदारी है
इस operating system में लगता है यह management ठीक से नहीं हुआ
ज़्यादा पुराने armv4 architecture पर आधारित मेरा Gentoo ARM SBC, latest gcc/clang updates के बाद भी लगातार ठीक चल रहा है grep CTARGET /etc/env.d/gcc -r /etc/env.d/gcc/armv4tl-softfloat-linux-gnueabi-11.3.0:CTARGET="armv4tl-softfloat-linux-gnueabi"
/etc/env.d user session के default environment variables define करने वाली Gentoo-specific directory है
Clang में उस directory को पढ़ने की कोई capability नहीं है, इसलिए यह मानकर नहीं चलना चाहिए कि यह दूसरे distributions में भी होगी
बस Gentoo की compiler configuration target चुनने के लिए CTARGET environment variable पढ़ती है, और Gentoo उस value को set करने के लिए /etc/env.d का इस्तेमाल करता है
लेख में यह नहीं बताया गया कि यह Debian है या Raspbian, और अगर Debian है तो armel port है या armhf port
उस जानकारी के बिना LLVM किस instruction set के लिए compile कर रहा है, इस पर बहस करने का बहुत मतलब नहीं है। यह LLVM के native target configuration पर निर्भर मुद्दा है
संदर्भ के लिए, Debian का llvm-toolchaim-snapshot अभी भी armel को support करता है, जो ARMv5T को baseline मानता है। हालांकि फिलहाल LLVM की OpenMP library में एक अलग bug है, इसलिए build सफल नहीं होता
अजीब बात यह है कि Clang binary खुद तो Pi B+ के compatible instruction set में compile की गई है, लेकिन असल में Pi B+ compatible instruction set को target नहीं कर रही
यह सच में अजीब है। इसे cross compiler की तरह इस्तेमाल करने को नहीं कहा जा रहा, इसलिए theory में host और target एक जैसे होने चाहिए
शायद image Raspbian की होगी। ऐसा मानने से बचने की कोई वजह नहीं दिखती
dpkg-architecture command का output और /etc/os-release file की contents पता हों तो मदद मिलेगी
उसके बिना उपयोगी comment करना मुश्किल है
title अफ़सोसजनक रूप से सनसनीखेज़ है
यह default target change है, और clang अभी भी Pi B+ के लिए binaries build कर सकता है
बस architecture को explicitly specify करना होगा। इसलिए title को थोड़ा बदलना बेहतर लगेगा, ताकि यह ज़्यादा साफ़ दिखे कि बात default settings में बदलाव की है
अगर target machine पर ही build करने के बावजूद वह उसी target machine के लिए binary नहीं बना पा रहा, तो यह इतना भी सनसनीखेज़ नहीं लगता
ARM पर कोई program क्यों नहीं चल रहा, इसे debug करते समय शायद लगभग इसी तरह approach करना चाहिए—यह दिलचस्प लगा
मेरे पास एक Unity Linux build है जो container के अंदर नहीं चलता; Docker चलाते समय amd64 flag पास करने पर भी Unity mono ऐसे system call करने की कोशिश करता है जिन्हें वह इस्तेमाल नहीं कर सकता
workaround मिल गया, इसलिए अभी debug नहीं किया। developer mode चालू करके build settings बदल दीं ताकि mono का इस्तेमाल न हो
कभी और सीखने के लिए इसे फिर से गहराई में देखना होगा
1 टिप्पणियां
Hacker News टिप्पणियाँ
Raspberry Pi में इस्तेमाल हुई ARM पीढ़ियों के इतिहास को देखें तो यह सचमुच चौंकाने वाली बात है कि चिप कितनी पुरानी थी
2014 में जब Raspberry Pi B+ आया, तब भी उसमें इस्तेमाल ARM1176 core 2003 का था, यानी वह पहले से ही 11 साल पुराना था
इसलिए किसी और प्लेटफ़ॉर्म, जैसे नए Raspberry Pi पर बिल्ड करते समय compatible code बनाने के लिए architecture flags साफ़-साफ़ बताने पड़ें, यह अजीब नहीं है
हालांकि अगर Raspberry Pi B+ पर ही बिल्ड करते समय भी सही architecture default में सेट नहीं हो रहा है, तो यह distro defaults की तरफ़ की configuration error जैसा लगता है
ऐसे products में कीमत के कारण ज़रूरत से ज़्यादा compute performance डालना बहुत कम होता है
पोस्ट में लिखा है कि “काफी तेज़ Pi 4B build host से binary लेकर इस पुराने device पर चलाने की कोशिश की, तो illegal instruction आया”
यह कुछ वैसा ही है जैसे Windows 11 पर नए MSVC से build की गई .EXE को Windows XP वाले पुराने PC पर चलाने की कोशिश करना
शायद Pi 4B पर चलने वाला पूरा Pi distro भी B+ पर न चले, और kernel भी उसी तरह compile किया गया हो सकता है
लगता है कि पोस्ट या लेख में इसे साफ़ तौर पर नहीं बताया गया, लेकिन क्या यह bug नहीं है?
LLVM bugs में खोजा तो लगभग इसी issue जैसा एक item मिला, लेकिन वह 2012 का bug है और बंद हो चुका है। आख़िरी कुछ comments देखने पर लगा कि शायद वह असल में ठीक नहीं हुआ था, लेकिन मैंने बस सरसरी तौर पर देखा है, इसलिए संभव है कि मैं ग़लत समझा होऊँ
https://github.com/llvm/llvm-project/issues/13989
दोबारा देखने पर पोस्ट के अंत में कहा गया था कि target को explicitly पास करने पर काम करने वाला program बनता है। तो यह किसी तरह का configuration bug लगता है, और Unix में मुझे लगता है कि default target current processor होना चाहिए, लेकिन पक्का नहीं हूँ
जिस bug को link किया है, वह शायद target सही तरह set करने के बाद भी गलत code बनाने की समस्या थी, और अच्छी बात है कि अभी स्थिति वैसी नहीं लगती
Rachel की समस्या compiler को armv6 target करने के लिए बताने से हल हो गई, इसलिए वह bug पहले ही ठीक हो चुका है और यह issue अलग लगता है
जिस database पर मैं काम करता हूँ, ClickHouse, वह बहुत पुराने hardware के साथ compatibility बनाए रखने के लिए काफ़ी कोशिश करता है
standard ARM binary 2016 के Armv8.2 की मांग करती है और Raspberry Pi 2 के बाद वाले models पर इस्तेमाल की जा सकती है। x86 binary लगभग 2010 के आसपास के ऐसे hardware पर चलती है जिसमें fast CRC के लिए SSE4.2 और pclmul* instructions हों
हम Armv8.0 और सिर्फ़ SSE2 वाले systems के लिए भी binaries build करते हैं, लेकिन उन्हें CI से test नहीं करते। fast install script target host के हिसाब से सही binary download करके unzip कर देती है
backward compatibility और नई AArch64 generations की CPU features का उपयोग करने के बीच balance बनाना कुल मिलाकर मुश्किल लगता है
https://en.wikipedia.org/wiki/AArch64
तंग budget वाले संस्थान, जैसे emerging countries की universities, या ऐसे hobby users जिनके पास hardware upgrade की क्षमता नहीं है, हैरान करने वाली संख्या में मिले
तकनीकी रूप से /proc/cpuinfo के CPU flags हमेशा compiler को दिए जाने वाले -march= flags से match नहीं करते, यह काफ़ी झंझट भरा था। जैसे "lrcpc" और "rcpc" अलग-अलग तरह से दिखते हैं
इसे ठीक से चलाने के लिए असल में दो तरह के flag sets maintain करने पड़ते हैं
समस्या शायद bookworm के मौजूदा clang-13 package में configured target बदलने की है
खास तौर पर, bullseye और clang-11 में default target armv6k-unknown-linux-gnueabihf है, जबकि bookworm और clang-13 में arm-unknown-linux-gnueabihf है
या फिर LLVM की तरफ़ उस build configuration का default बदल गया हो सकता है
लेकिन [1] और [2] की तुलना करने पर rules file में “अगर DEB_HOST_ARCH armhf है तो LLVM_HOST_TRIPLE को armv6k पर set करें” वाला साफ़ test है, इसलिए यह build configuration में बदलाव की पुष्टि करता लगता है
[1] http://raspbian.raspberrypi.org/raspbian/pool/main/l/llvm-to...
[2] http://raspbian.raspberrypi.org/raspbian/pool/main/l/llvm-to...
लगता है यह जानबूझकर किया गया बदलाव नहीं होगा
आसपास की टिप्पणियों में जैसे /etc/env.d/gcc का ज़िक्र था, काफ़ी संभावना है कि यह environment से जानकारी पढ़ने के तरीके से जुड़ा हो
default triple शायद arm-unknown-linux जैसा कोई मान होगा, अगर clang को ज़्यादा specific जानकारी न मिले या पास न की जाए; लगता है ज़्यादा specific target बताने वाला mechanism टूट गया है
इसका मतलब यह हो सकता है कि ARMv6 buildbot नहीं है, या buildbot तो है लेकिन वहाँ implicit configuration अभी भी ठीक से काम कर रही है
LLVM सचमुच बहुत अच्छा cross compiler है। किसी भी target से किसी भी target के लिए बिना बड़े झंझट के build किया जा सकता है
Clang उतना आकर्षक नहीं है। अगर वह target support के साथ build हुआ है, और आप उसे ठीक से बता सकें कि किस target के लिए build करना है, तो शायद वह सही काम करेगा। इस लेख में भी अनुमान गलत था, लेकिन ज़्यादा जानकारी देने पर यह सही तरह काम करने लगा
runtime libraries की स्थिति और खराब है। भले ही आपने armv4 जैसे target के लिए build किया हो, आपको उसके मुताबिक libc आदि ढूँढनी होगी, और compiler को उन libraries और headers की location बतानी पड़ सकती है; इस हिस्से की details अभी भी साफ़ नहीं हैं
पुराने Synology NAS के लिए binaries build करते समय मुझे भी ऐसी ही समस्या आई थी
clang/clang++ /etc/env.d/gcc से target flags और profiles पढ़ते हैं, और इन्हें सही बनाए रखना operating system की ज़िम्मेदारी है
इस operating system में लगता है यह management ठीक से नहीं हुआ
ज़्यादा पुराने armv4 architecture पर आधारित मेरा Gentoo ARM SBC, latest gcc/clang updates के बाद भी लगातार ठीक चल रहा है
grep CTARGET /etc/env.d/gcc -r/etc/env.d/gcc/armv4tl-softfloat-linux-gnueabi-11.3.0:CTARGET="armv4tl-softfloat-linux-gnueabi"Clang में उस directory को पढ़ने की कोई capability नहीं है, इसलिए यह मानकर नहीं चलना चाहिए कि यह दूसरे distributions में भी होगी
बस Gentoo की compiler configuration target चुनने के लिए CTARGET environment variable पढ़ती है, और Gentoo उस value को set करने के लिए /etc/env.d का इस्तेमाल करता है
लेख में यह नहीं बताया गया कि यह Debian है या Raspbian, और अगर Debian है तो armel port है या armhf port
उस जानकारी के बिना LLVM किस instruction set के लिए compile कर रहा है, इस पर बहस करने का बहुत मतलब नहीं है। यह LLVM के native target configuration पर निर्भर मुद्दा है
संदर्भ के लिए, Debian का llvm-toolchaim-snapshot अभी भी armel को support करता है, जो ARMv5T को baseline मानता है। हालांकि फिलहाल LLVM की OpenMP library में एक अलग bug है, इसलिए build सफल नहीं होता
यह सच में अजीब है। इसे cross compiler की तरह इस्तेमाल करने को नहीं कहा जा रहा, इसलिए theory में host और target एक जैसे होने चाहिए
शायद image Raspbian की होगी। ऐसा मानने से बचने की कोई वजह नहीं दिखती
dpkg-architecturecommand का output और/etc/os-releasefile की contents पता हों तो मदद मिलेगीउसके बिना उपयोगी comment करना मुश्किल है
title अफ़सोसजनक रूप से सनसनीखेज़ है
यह default target change है, और clang अभी भी Pi B+ के लिए binaries build कर सकता है
बस architecture को explicitly specify करना होगा। इसलिए title को थोड़ा बदलना बेहतर लगेगा, ताकि यह ज़्यादा साफ़ दिखे कि बात default settings में बदलाव की है
ARM पर कोई program क्यों नहीं चल रहा, इसे debug करते समय शायद लगभग इसी तरह approach करना चाहिए—यह दिलचस्प लगा
मेरे पास एक Unity Linux build है जो container के अंदर नहीं चलता; Docker चलाते समय amd64 flag पास करने पर भी Unity mono ऐसे system call करने की कोशिश करता है जिन्हें वह इस्तेमाल नहीं कर सकता
workaround मिल गया, इसलिए अभी debug नहीं किया। developer mode चालू करके build settings बदल दीं ताकि mono का इस्तेमाल न हो
कभी और सीखने के लिए इसे फिर से गहराई में देखना होगा