WebAssembly को ज़्यादा तेज़ी से डीबग करना

Philip Pfaffe
GitHub
Kim-Anh Tran
Kim-Anh Tran
X GitHub
Eric Leese
Eric Leese
GitHub
Sam Clegg
GitHub

Chrome Dev समिट 2020 में, हमने पहली बार वेब पर WebAssembly ऐप्लिकेशन के लिए, Chrome की डीबग करने की सुविधा का डेमो दिया. तब से, टीम ने बड़े और बहुत बड़े ऐप्लिकेशन के लिए, डेवलपर अनुभव को स्केल करने में काफ़ी मेहनत की है. इस पोस्ट में, हम आपको अलग-अलग टूल में जोड़े गए (या काम करने वाले) बटन और उनका इस्तेमाल करने का तरीका दिखाएंगे!

बड़े स्तर पर डीबग करने की सुविधा

आइए, 2020 में हमने जहां से छोड़ा था वहीं से शुरू करते हैं. उस समय हम इस उदाहरण पर गौर कर रहे थे:

#include <SDL2/SDL.h>
#include <complex>

int main() {
  // Init SDL.
  int width = 600, height = 600;
  SDL_Init(SDL_INIT_VIDEO);
  SDL_Window* window;
  SDL_Renderer* renderer;
  SDL_CreateWindowAndRenderer(width, height, SDL_WINDOW_OPENGL, &window,
                              &renderer);

  // Generate a palette with random colors.
  enum { MAX_ITER_COUNT = 256 };
  SDL_Color palette[MAX_ITER_COUNT];
  srand(time(0));
  for (int i = 0; i < MAX_ITER_COUNT; ++i) {
    palette[i] = {
        .r = (uint8_t)rand(),
        .g = (uint8_t)rand(),
        .b = (uint8_t)rand(),
        .a = 255,
    };
  }

  // Calculate and draw the Mandelbrot set.
  std::complex<double> center(0.5, 0.5);
  double scale = 4.0;
  for (int y = 0; y < height; y++) {
    for (int x = 0; x < width; x++) {
      std::complex<double> point((double)x / width, (double)y / height);
      std::complex<double> c = (point - center) * scale;
      std::complex<double> z(0, 0);
      int i = 0;
      for (; i < MAX_ITER_COUNT - 1; i++) {
        z = z * z + c;
        if (abs(z) > 2.0)
          break;
      }
      SDL_Color color = palette[i];
      SDL_SetRenderDrawColor(renderer, color.r, color.g, color.b, color.a);
      SDL_RenderDrawPoint(renderer, x, y);
    }
  }

  // Render everything we've drawn to the canvas.
  SDL_RenderPresent(renderer);

  // SDL_Quit();
}

यह अब भी एक छोटा उदाहरण है. इसलिए, आपको कोई ऐसी समस्या नहीं दिखेगी जो किसी बड़े ऐप्लिकेशन में दिख सकती है. हालांकि, हम आपको नई सुविधाओं के बारे में बता सकते हैं. इसे सेट अप करना तेज़ और आसान है. इसे खुद आज़माएं!

पिछली पोस्ट में, हमने इस उदाहरण को कंपाइल और डीबग करने का तरीका बताया था. आइए, फिर से ऐसा करते हैं. साथ ही, //performance// को भी देखें:

$ emcc -sUSE_SDL=2 -g -O0 -o mandelbrot.html mandelbrot.cc -sALLOW_MEMORY_GROWTH

इस निर्देश से 3 एमबी Wasm बाइनरी बनती है. साथ ही, इसमें सबसे ज़्यादा डीबग की जानकारी होती है. llvm-objdump टूल [1] की मदद से इसकी पुष्टि की जा सकती है. उदाहरण के लिए:

$ llvm-objdump -h mandelbrot.wasm

mandelbrot.wasm:        file format wasm

Sections:
Idx Name          Size     VMA      Type
  0 TYPE          0000026f 00000000
  1 IMPORT        00001f03 00000000
  2 FUNCTION      0000043e 00000000
  3 TABLE         00000007 00000000
  4 MEMORY        00000007 00000000
  5 GLOBAL        00000021 00000000
  6 EXPORT        0000014a 00000000
  7 ELEM          00000457 00000000
  8 CODE          0009308a 00000000 TEXT
  9 DATA          0000e4cc 00000000 DATA
 10 name          00007e58 00000000
 11 .debug_info   000bb1c9 00000000
 12 .debug_loc    0009b407 00000000
 13 .debug_ranges 0000ad90 00000000
 14 .debug_abbrev 000136e8 00000000
 15 .debug_line   000bb3ab 00000000
 16 .debug_str    000209bd 00000000

इस आउटपुट में, जनरेट की गई wasm फ़ाइल के सभी सेक्शन दिखते हैं. इनमें से ज़्यादातर वेब असेंबली के स्टैंडर्ड सेक्शन होते हैं. हालांकि, इसमें कई कस्टम सेक्शन भी होते हैं, जिनका नाम .debug_ से शुरू होता है. बाइनरी में डीबग की जानकारी यहीं होती है! अगर हम सभी साइज़ को जोड़ें, तो हम देखते हैं कि डीबग की जानकारी, हमारी 3 एमबी फ़ाइल का करीब 2.3 एमबी है. अगर हम emcc कमांड को भी time करते हैं, तो हमें पता चलता है कि हमारी मशीन पर इसे चलने में करीब 1.5 सेकंड लगे. ये संख्याएं एक अच्छा बेसलाइन बनाती हैं, लेकिन ये इतनी कम हैं कि शायद कोई भी इन पर ध्यान न दे. हालांकि, असली ऐप्लिकेशन में डीबग बाइनरी आसानी से जीबी के साइज़ तक पहुंच सकती है और इसे बनने में कुछ मिनट लग सकते हैं!

Binaryen को स्किप करना

Emscripten के साथ Wasm ऐप्लिकेशन बनाते समय, इसके आखिरी चरणों में से एक Binaryen ऑप्टिमाइज़र चल रहा है. Binaryen एक कंपाइलर टूलकिट है, जो WebAssembly जैसी बाइनरी को ऑप्टिमाइज़ करता है और उन्हें कानूनी बनाता है. इस बिल्ड के हिस्से के तौर पर बाइनरीयन चलाना बहुत महंगा है, लेकिन इसकी ज़रूरत कुछ ही स्थितियों में होती है. डीबग बिल्ड के लिए, Binaryen पास की ज़रूरत को पूरा किए बिना, बिल्ड में लगने वाले समय को काफ़ी कम किया जा सकता है. आम तौर पर, बाइनरी पास की ज़रूरत 64 बिट पूर्णांक वैल्यू वाले फ़ंक्शन हस्ताक्षर को कानूनी तौर पर तैयार करने के लिए होती है. -sWASM_BIGINT का इस्तेमाल करके, WebAssembly BigInt इंटिग्रेशन में ऑप्ट-इन करके, हम इस समस्या से बच सकते हैं.

$ emcc -sUSE_SDL=2 -g -O0 -o mandelbrot.html mandelbrot.cc -sALLOW_MEMORY_GROWTH -sWASM_BIGINT -sERROR_ON_WASM_CHANGES_AFTER_LINK

हमने -sERROR_ON_WASM_CHANGES_AFTER_LINK फ़्लैग को भी शामिल किया है. इससे यह पता चलता है कि Binaryen कब चल रहा है और बाइनरी को अनचाहे में कब फिर से लिखा जा रहा है. इससे, हम यह पक्का कर सकते हैं कि हम सही दिशा में आगे बढ़ रहे हैं.

भले ही, हमारा उदाहरण काफ़ी छोटा है, लेकिन Binaryen को स्किप करने का असर अब भी दिख रहा है! time के मुताबिक, यह निर्देश 1 सेकंड से कम समय में चलता है, इसलिए यह पहले से आधा सेकंड तेज़ है!

बेहतर बदलाव

इनपुट फ़ाइल को स्कैन न करना

आम तौर पर, Emscripten प्रोजेक्ट को लिंक करते समय, emcc सभी इनपुट ऑब्जेक्ट फ़ाइलों और लाइब्रेरी को स्कैन करेगा. यह ऐसा इसलिए करता है, ताकि आपके प्रोग्राम में JavaScript लाइब्रेरी फ़ंक्शन और नेटिव सिंबल के बीच सटीक डिपेंडेंसी लागू की जा सके. बड़े प्रोजेक्ट के लिए, llvm-nm का इस्तेमाल करके इनपुट फ़ाइलों की अतिरिक्त स्कैनिंग करने पर, लिंक करने में काफ़ी समय लग सकता है.

इसके बजाय, -sREVERSE_DEPS=all के साथ चलाया जा सकता है, जो emcc को JavaScript फ़ंक्शन की सभी संभावित नेटिव डिपेंडेंसी शामिल करने के लिए कहता है. इसमें कोड का साइज़ थोड़ा ज़्यादा होता है, लेकिन इससे लिंक करने में लगने वाला समय कम हो सकता है. साथ ही, यह डीबग बिल्ड के लिए भी फ़ायदेमंद हो सकता है.

उदाहरण के तौर पर दिए गए छोटे प्रोजेक्ट के लिए इससे कोई फ़र्क़ नहीं पड़ता. हालांकि, अगर आपके प्रोजेक्ट में सैकड़ों या हज़ारों ऑब्जेक्ट फ़ाइलें हैं, तो इससे लिंक होने का समय काफ़ी बेहतर हो सकता है.

“name” सेक्शन को हटाना

बड़े प्रोजेक्ट में, खास तौर पर उन प्रोजेक्ट में जिनमें C++ टेंप्लेट का ज़्यादा इस्तेमाल किया गया है, WebAssembly का “name” सेक्शन बहुत बड़ा हो सकता है. हमारे उदाहरण में, यह फ़ाइल के कुल साइज़ का सिर्फ़ एक छोटा हिस्सा है (ऊपर llvm-objdump का आउटपुट देखें). हालांकि, कुछ मामलों में यह काफ़ी अहम हो सकता है. अगर आपके ऐप्लिकेशन का “नाम” सेक्शन बहुत बड़ा है और डीबग करने की आपकी ज़रूरतों के लिए बौनी डीबग जानकारी काफ़ी है, तो “नाम” सेक्शन को हटाना फ़ायदेमंद हो सकता है:

$ emstrip --no-strip-all --remove-section=name mandelbrot.wasm

इससे, DWARF डीबग सेक्शन को बरकरार रखते हुए, WebAssembly के “name” सेक्शन को हटा दिया जाएगा.

डीबग फ़िज़न

ज़्यादा डीबग डेटा वाली बाइनरी, न सिर्फ़ बिल्ड के समय पर असर डालती हैं, बल्कि डीबग करने में भी ज़्यादा समय लेती हैं. डीबगर को डेटा लोड करना होता है और उसके लिए इंडेक्स बनाना होता है, ताकि वह "लोकल वैरिएबल x का टाइप क्या है?" जैसी क्वेरी का तुरंत जवाब दे सके.

डीबग फ़िज़न की मदद से, किसी बाइनरी के लिए डीबग की जानकारी को दो हिस्सों में बांटा जा सकता है: पहला हिस्सा बाइनरी में रहता है और दूसरा हिस्सा, DWARF ऑब्जेक्ट (.dwo) फ़ाइल में होता है. Emscripten में -gsplit-dwarf फ़्लैग पास करके, इसे चालू किया जा सकता है:

$ emcc -sUSE_SDL=2 -g -gsplit-dwarf -gdwarf-5 -O0 -o mandelbrot.html mandelbrot.cc  -sALLOW_MEMORY_GROWTH -sWASM_BIGINT -sERROR_ON_WASM_CHANGES_AFTER_LINK

यहां हम अलग-अलग निर्देश दिखाते हैं. साथ ही, यह भी बताते हैं कि डीबग डेटा के बिना, डीबग डेटा के साथ, और आखिर में डीबग डेटा और डीबग फ़िज़न, दोनों के साथ कंपाइल करने पर कौनसी फ़ाइलें जनरेट होती हैं.

अलग-अलग निर्देश और कौनसी फ़ाइलें जनरेट होती हैं

DWARF डेटा को बांटते समय, डीबग डेटा का एक हिस्सा बाइनरी के साथ रहता है, जबकि ज़्यादातर हिस्सा mandelbrot.dwo फ़ाइल में डाला जाता है (जैसा कि ऊपर दिखाया गया है).

mandelbrot के लिए, हमारे पास सिर्फ़ एक सोर्स फ़ाइल है. हालांकि, आम तौर पर प्रोजेक्ट इससे बड़े होते हैं और इनमें एक से ज़्यादा फ़ाइलें शामिल होती हैं. डीबग फ़िज़न, हर एक के लिए एक .dwo फ़ाइल जनरेट करता है. डीबगर के मौजूदा बीटा वर्शन (0.1.6.1615) के लिए, हमें उन सभी को एक तथाकथित DWARF पैकेज (.dwp) में इस तरह इकट्ठा करना होगा, ताकि अलग-अलग डीबग की इस जानकारी को लोड किया जा सके:

$ emdwp -e mandelbrot.wasm -o mandelbrot.dwp

dwo फ़ाइलों को DWARF पैकेज में बंडल करना

अलग-अलग ऑब्जेक्ट से DWARF पैकेज बनाने का एक फ़ायदा यह है कि आपको सिर्फ़ एक और फ़ाइल देने की ज़रूरत होती है! फ़िलहाल, हम आने वाले समय में रिलीज़ होने वाले वर्शन में, सभी अलग-अलग ऑब्जेक्ट को लोड करने पर काम कर रहे हैं.

DWARF 5 में क्या खास है?

आपने देखा होगा कि हमने ऊपर दिए गए emcc कमांड में, -gdwarf-5 के तौर पर एक और फ़्लैग जोड़ा है. DWARF सिंबल के वर्शन 5 को चालू करना, डीबगिंग को तेज़ी से शुरू करने का एक और तरीका है. फ़िलहाल, यह वर्शन डिफ़ॉल्ट तौर पर उपलब्ध नहीं है. इसकी मदद से, मुख्य बाइनरी में कुछ ऐसी जानकारी सेव की जाती है जो डिफ़ॉल्ट वर्शन 4 में मौजूद नहीं होती. खास तौर पर, हम सिर्फ़ मुख्य बाइनरी से सोर्स फ़ाइलों का पूरा सेट तय कर सकते हैं. इससे डीबगर, पूरे सोर्स ट्री को दिखाने और ब्रेकपॉइंट सेट करने जैसी बुनियादी कार्रवाइयां कर सकता है. इसके लिए, उसे पूरे सिंबल डेटा को लोड और पार्स करने की ज़रूरत नहीं पड़ती. इससे, स्प्लिट सिंबल की मदद से डीबग करने की प्रोसेस बहुत तेज़ हो जाती है. इसलिए, हम हमेशा -gsplit-dwarf और -gdwarf-5 कमांड लाइन फ़्लैग का एक साथ इस्तेमाल करते हैं!

DWARF5 डीबग फ़ॉर्मैट की मदद से, हमें एक और काम की सुविधा का ऐक्सेस भी मिलता है. यह डीबग डेटा में एक नाम इंडेक्स उपलब्ध कराता है, जो -gpubnames फ़्लैग को पास करने पर जनरेट होता है:

$ emcc -sUSE_SDL=2 -g -gdwarf-5 -gsplit-dwarf -gpubnames -O0 -o mandelbrot.html mandelbrot.cc -sALLOW_MEMORY_GROWTH -sWASM_BIGINT -sERROR_ON_WASM_CHANGES_AFTER_LINK

डीबग करने के सेशन के दौरान, सिंबल लुकअप तब अक्सर होता है, जब किसी इकाई को उसके नाम से खोजा जाता है. उदाहरण के लिए, किसी वैरिएबल या टाइप को खोजते समय. नाम का इंडेक्स, खोज के लिए इस्तेमाल होने वाली इस खोज को तेज़ी से आगे बढ़ाता है. ऐसा करने के लिए, यह नाम कंपाइलेशन यूनिट की ओर इशारा करता है. नाम सूची के बिना, पूरे डीबग डेटा को खोजना होगा. इससे, हमें वह कंपाइलेशन यूनिट मिल पाएगी जो नाम वाली उस इकाई के बारे में बताती है जिसे हम खोज रहे हैं.

दिलचस्पी रखने वालों के लिए: डीबग डेटा देखना

DWARF डेटा को देखने के लिए, llvm-dwarfdump का इस्तेमाल किया जा सकता है. आइए, इसे आज़माते हैं:

llvm-dwarfdump mandelbrot.wasm

इससे हमें उन “कंपाइल यूनिट” (सोर्स फ़ाइलों) के बारे में खास जानकारी मिलती है जिनके लिए हमारे पास डीबग करने की जानकारी होती है. इस उदाहरण में, हमारे पास सिर्फ़ mandelbrot.cc के लिए डीबग की जानकारी है. सामान्य जानकारी से हमें पता चलेगा कि हमारे पास स्केलेटन यूनिट है. इसका मतलब है कि हमारे पास इस फ़ाइल का अधूरा डेटा है. साथ ही, एक अलग .dwo फ़ाइल है जिसमें बचे हुए डीबग की जानकारी मौजूद है:

mandelbrot.wasm और डीबग की जानकारी

इस फ़ाइल में मौजूद अन्य टेबल भी देखी जा सकती हैं. जैसे, वह लाइन टेबल जिसमें Wasm बाइट कोड को C++ लाइनों पर मैप किया गया है (llvm-dwarfdump -debug-line का इस्तेमाल करके देखें).

हम अलग .dwo फ़ाइल में मौजूद डीबग की जानकारी भी देख सकते हैं:

llvm-dwarfdump mandelbrot.dwo

mandelbrot.wasm और डीबग की जानकारी

कम शब्दों में: डीबग फ़िज़न का इस्तेमाल करने का क्या फ़ायदा है?

अगर बड़े ऐप्लिकेशन के साथ काम किया जा रहा है, तो डीबग की जानकारी को अलग-अलग हिस्सों में बांटने के कई फ़ायदे हैं:

  1. ज़्यादा तेज़ी से लिंक करना: अब लिंकर को पूरी डीबग जानकारी को पार्स करने की ज़रूरत नहीं है. आम तौर पर, लिंकर को बाइनरी में मौजूद पूरे DWARF डेटा को पार्स करना पड़ता है. डीबग की जानकारी के बड़े हिस्सों को अलग-अलग फ़ाइलों में बांटकर, लिंकर छोटी बाइनरी के साथ काम करते हैं. इससे लिंक करने में कम समय लगता है. यह बात खास तौर पर बड़े ऐप्लिकेशन के लिए सही है.

  2. ज़्यादा तेज़ी से डीबग करने की सुविधा: डीबगर, कुछ सिंबल को खोजने के लिए .dwo/.dwp फ़ाइलों में मौजूद दूसरे सिंबल को पार्स नहीं कर सकता. कुछ लुकअप के लिए, हमें अतिरिक्त डीबग डेटा देखने की ज़रूरत नहीं होती. जैसे, wasm से C++ फ़ाइलों की लाइन मैपिंग के अनुरोध. इससे हमें समय की बचत होती है, क्योंकि हमें अतिरिक्त डीबग डेटा को लोड और पार्स करने की ज़रूरत नहीं होती.

पहला: अगर आपके सिस्टम पर llvm-objdump का नया वर्शन नहीं है और emsdk का इस्तेमाल किया जा रहा है, तो आपको यह emsdk/upstream/bin डायरेक्ट्री में मिल सकता है.

झलक दिखाने वाले चैनलों को डाउनलोड करें

Chrome कैनरी, डेवलपर या बीटा को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. इन झलक वाले चैनलों की मदद से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, इनसे आपको वेब प्लैटफ़ॉर्म के सबसे नए एपीआई की जांच करने में मदद मिलती है. इसके अलावा, इनकी मदद से उपयोगकर्ताओं से पहले ही अपनी साइट पर समस्याओं का पता लगाया जा सकता है!

Chrome DevTools की टीम से संपर्क करना

DevTools से जुड़ी नई सुविधाओं, अपडेट या किसी भी अन्य चीज़ के बारे में चर्चा करने के लिए, यहां दिए गए विकल्पों का इस्तेमाल करें.