การแก้ไขข้อบกพร่อง WebAssembly ด้วยเครื่องมือสมัยใหม่

Ingvar Stepanyan

หมายเหตุ: หากสนใจช่วยปรับปรุงเครื่องมือสำหรับนักพัฒนาเว็บ ลงชื่อสมัครเข้าร่วมการศึกษาวิจัยผู้ใช้ของ Google ได้ที่นี่

ถนนจนถึงตอนนี้

เมื่อ 1 ปีที่แล้ว Chrome ได้ประกาศการรองรับเบื้องต้น สำหรับการแก้ไขข้อบกพร่อง WebAssembly แบบเนทีฟใน Chrome DevTools

เราได้สาธิตการสนับสนุนขั้นพื้นฐานและพูดเกี่ยวกับโอกาสในการใช้ข้อมูล DWARF แทนการเปิดแผนที่แหล่งที่มาในอนาคต

• การค้นหาชื่อตัวแปร
• รูปแบบการพิมพ์
• การประเมินนิพจน์ในภาษาต้นฉบับ
• ...และอีกมากมาย

วันนี้เรายินดีที่จะได้นำเสนอฟีเจอร์ตามที่สัญญาใช้จริง และความคืบหน้าที่ทีม Emscripten และ Chrome DevTools ดำเนินการในปีนี้ โดยเฉพาะสำหรับแอป C และ C++

ก่อนเริ่มต้น โปรดทราบว่าประสบการณ์ใหม่นี้ยังเป็นเวอร์ชันเบต้าอยู่ คุณต้องยอมรับความเสี่ยงจากการใช้เครื่องมือเวอร์ชันล่าสุดทั้งหมดเอง และหากพบปัญหาใดๆ โปรดรายงานไปที่ https://bugs.chromium.org/p/chromium/issues/entry?template=DevTools+issue

เรามาเริ่มด้วยตัวอย่าง C ง่ายๆ เหมือนครั้งที่แล้ว:

#include <stdlib.h>

void assert_less(int x, int y) {
  if (x >= y) {
    abort();
  }
}

int main() {
  assert_less(10, 20);
  assert_less(30, 20);
}

ในการรวบรวม เราจะใช้ Last Emscripten และส่งผ่านแฟล็ก -g เช่นเดียวกับโพสต์ต้นฉบับเพื่อรวมข้อมูลการแก้ไขข้อบกพร่อง ดังนี้

emcc -g temp.c -o temp.html

ตอนนี้เราแสดงหน้าที่สร้างขึ้นจากเซิร์ฟเวอร์ HTTP localhost ได้แล้ว (เช่น แสดงด้วย serve) และเปิดหน้าดังกล่าวใน Chrome Canary เวอร์ชันล่าสุด

และครั้งนี้เราต้องการส่วนขยายผู้ช่วยที่ผสานรวมกับ Chrome DevTools และช่วยให้เข้าใจข้อมูลการแก้ไขข้อบกพร่องทั้งหมดที่เข้ารหัสในไฟล์ WebAssembly โปรดติดตั้งโดยไปที่ ลิงก์ goo.gle/wasm-debugging-extension

คุณจะต้องเปิดใช้การแก้ไขข้อบกพร่องของ WebAssembly ในการทดสอบเครื่องมือสำหรับนักพัฒนาเว็บด้วย เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome คลิกไอคอนรูปเฟือง (⚙) ที่มุมขวาบนของแผงเครื่องมือสำหรับนักพัฒนาเว็บ ไปที่แผงการทดสอบ แล้วเลือกการแก้ไขข้อบกพร่องของ WebAssembly: เปิดใช้การรองรับ DWARF

เมื่อปิดการตั้งค่า เครื่องมือสำหรับนักพัฒนาเว็บจะแนะนำให้โหลดตัวเองซ้ำเพื่อใช้การตั้งค่า ดังนั้นมาทำกันเลย และนั่นคือการตั้งค่าแบบครั้งเดียว

ตอนนี้เราสามารถกลับไปที่แผงแหล่งที่มา เปิดใช้หยุดชั่วคราวเมื่อข้อยกเว้น (ไอคอน ⏸) จากนั้นเลือกหยุดชั่วคราวเมื่อข้อยกเว้นที่พบ แล้วโหลดหน้าเว็บซ้ำ คุณควรเห็นเครื่องมือสำหรับนักพัฒนาเว็บหยุดชั่วคราวจากข้อยกเว้นต่อไปนี้

โดยค่าเริ่มต้น โค้ดจะหยุดบนโค้ดกาวที่สร้างโดย Emscripten แต่ทางด้านขวา คุณจะเห็นมุมมอง Call Stack ที่แสดงถึงสแต็กเทรซข้อผิดพลาด และไปยังบรรทัด C เดิมที่เรียกใช้ abort

ตอนนี้ หากดูในมุมมองขอบเขต คุณจะเห็นชื่อเดิมและค่าของตัวแปรในโค้ด C/C++ และไม่จำเป็นต้องทราบว่าชื่อที่เปลี่ยนแปลงอย่างไร เช่น $localN มีความหมายว่าอย่างไร และดูว่าชื่อเหล่านั้นเกี่ยวข้องกับซอร์สโค้ดที่คุณเขียนอย่างไร

วิธีนี้ไม่ได้ใช้กับค่าพื้นฐาน เช่น จำนวนเต็มเท่านั้น แต่ยังมีผลกับประเภทสารประกอบ เช่น โครงสร้าง คลาส อาร์เรย์ ฯลฯ ด้วย

การรองรับ Rich type

มาดูตัวอย่างที่ซับซ้อนมากขึ้นกัน คราวนี้เราจะวาดเศษส่วน Mandelbrot ด้วยโค้ด C++ ต่อไปนี้

#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();
}

คุณจะเห็นว่าแอปพลิเคชันนี้ยังมีขนาดเล็กอยู่เพราะเป็นไฟล์เดียวที่มีโค้ด 50 บรรทัด แต่คราวนี้ผมใช้ API ภายนอกบางส่วน เช่น ไลบรารี SDL สำหรับกราฟิก รวมถึงจำนวนที่ซับซ้อนจากไลบรารีมาตรฐาน C++ ด้วย

ฉันจะคอมไพล์ด้วยแฟล็ก -g เดียวกันกับด้านบนเพื่อรวมข้อมูลการแก้ไขข้อบกพร่อง และจะขอให้ Emscripten จัดหาไลบรารี SDL2 และอนุญาตให้ใช้หน่วยความจำตามขนาดที่ต้องการด้วย

emcc -g mandelbrot.cc -o mandelbrot.html \
     -s USE_SDL=2 \
     -s ALLOW_MEMORY_GROWTH=1

เมื่อผมเข้าชมหน้าเว็บที่สร้างขึ้นในเบราว์เซอร์ ผมจะเห็นรูปทรงแฟร็กทัลที่สวยงาม พร้อมสีแบบสุ่ม ดังนี้

เมื่อเปิดเครื่องมือสำหรับนักพัฒนาเว็บ ฉันเห็นไฟล์ C++ ต้นฉบับอีกครั้ง อย่างไรก็ตาม ในครั้งนี้เราไม่มีข้อผิดพลาดในโค้ด (ว้าว!) เราลองมาตั้งค่าเบรกพอยท์ที่ตอนต้นของโค้ดแทน

เมื่อเราโหลดหน้านี้ซ้ำ โปรแกรมแก้ไขข้อบกพร่องจะหยุดชั่วคราวในที่มา C++ ของเรา

เราเห็นตัวแปรทั้งหมดทางด้านขวาอยู่แล้ว แต่ขณะนี้มีเพียง width และ height ที่เริ่มต้นเท่านั้น จึงไม่มีอะไรให้ตรวจสอบมากนัก

มาตั้งค่าเบรกพอยท์อีกจุดหนึ่งภายในลูป Mandelbrot หลักของเรา แล้วดำเนินการต่อไปเพื่อข้ามไปข้างหน้า

เมื่อถึงจุดนี้ palette ของเราเต็มไปด้วยสีแบบสุ่ม และเราสามารถขยายทั้งอาร์เรย์ รวมถึงโครงสร้าง SDL_Color แต่ละรายการ และตรวจสอบคอมโพเนนต์ของพวกเขาว่าทุกอย่างดูดีแล้ว (ตัวอย่างเช่น ช่อง "อัลฟา" จะตั้งค่าเป็นความทึบแสงเต็มเสมอ) ในทำนองเดียวกัน เราสามารถขยายและตรวจสอบส่วนจริงและส่วนจินตภาพของจำนวนเชิงซ้อนที่จัดเก็บในตัวแปร center ได้

หากต้องการเข้าถึงพร็อพเพอร์ตี้ที่ฝังอยู่ลึกซึ่งนำทางผ่านมุมมองขอบเขตได้ยาก คุณก็ใช้การประเมินคอนโซลได้เช่นกัน แต่โปรดทราบว่าระบบยังไม่รองรับนิพจน์ C++ ที่ซับซ้อนมากขึ้น

มาดำเนินการกันต่ออีกสัก 2-3 ครั้ง เราจะดูว่า x ภายในเปลี่ยนแปลงไปอย่างไรบ้างด้วยการดูในมุมมองขอบเขตอีกครั้ง การเพิ่มชื่อตัวแปรลงในรายการเฝ้าดู ประเมินค่าในคอนโซล หรือโดยการวางเมาส์เหนือตัวแปรในซอร์สโค้ด ดังนี้

จากตรงนี้ เราสามารถย้อนดูคำสั่ง C++ อย่างละเอียด และสังเกตการเปลี่ยนแปลงของตัวแปรอื่นๆ ด้วย ดังนี้

โอเค ทุกอย่างจะทำงานได้ดีเมื่อมีข้อมูลการแก้ไขข้อบกพร่อง แต่ถ้าเราต้องการแก้ไขข้อบกพร่องในโค้ดที่ไม่ได้สร้างขึ้นด้วยตัวเลือกการแก้ไขข้อบกพร่อง

การแก้ไขข้อบกพร่อง Raw WebAssembly

เช่น เราขอให้ Emscripten จัดเตรียมไลบรารี SDL ที่สร้างไว้ล่วงหน้าให้เรา แทนที่จะคอมไพล์ด้วยตนเองจากแหล่งที่มา ดังนั้นอย่างน้อยตอนนี้ โปรแกรมแก้ไขข้อบกพร่องก็ไม่สามารถค้นหาแหล่งที่มาที่เชื่อมโยงได้ มาเข้าสู่ SDL_RenderDrawColor อีกครั้งกัน

เรากลับมาสัมผัสประสบการณ์การแก้ไขข้อบกพร่องด้วย WebAssembly แบบข้อมูลดิบ

ตอนนี้ ก็ดูค่อนข้างน่ากลัวไม่ใช่สิ่งที่นักพัฒนาเว็บส่วนใหญ่จะต้องจัดการ แต่บางครั้งคุณอาจต้องการแก้ไขข้อบกพร่องของไลบรารีที่สร้างขึ้นโดยไม่มีข้อมูลการแก้ไขข้อบกพร่อง ไม่ว่าจะเป็นเพราะไลบรารีดังกล่าวเป็นไลบรารีของบุคคลที่ 3 ซึ่งคุณไม่สามารถควบคุมได้ หรือคุณเจอข้อบกพร่องอย่างใดอย่างหนึ่งที่เกิดขึ้นเฉพาะในเวอร์ชันที่ใช้งานจริงเท่านั้น

เพื่อช่วยในกรณีเหล่านั้น เราได้ทำการปรับปรุงบางอย่างในประสบการณ์การแก้ไขข้อบกพร่องพื้นฐานด้วย

อย่างแรกเลย หากก่อนหน้านี้คุณใช้การแก้ไขข้อบกพร่อง WebAssembly แบบข้อมูลดิบ คุณอาจสังเกตเห็นว่าตอนนี้การถอดแยกชิ้นส่วนทั้งหมดแสดงขึ้นในไฟล์เดียว ไม่ต้องเดาว่าฟังก์ชันใดของรายการแหล่งที่มา wasm-53834e3e/ wasm-53834e3e-7 จะสอดคล้องกับฟังก์ชันใด

สคีมการสร้างชื่อใหม่

นอกจากนี้เรายังได้ปรับปรุงชื่อในมุมมองการแยกชิ้นส่วนด้วย ก่อนหน้านี้คุณจะเห็นเพียงดัชนีตัวเลข หรือในกรณีที่ไม่เห็นชื่อฟังก์ชัน

ตอนนี้เรากำลังสร้างชื่อที่คล้ายคลึงกับเครื่องมือแยกชิ้นส่วนอื่นๆ โดยใช้คำแนะนำจากส่วนชื่อ WebAssembly, เส้นทางการนำเข้า/ส่งออก และสุดท้าย หากอื่นๆ ทั้งหมดล้มเหลว ให้สร้างชื่อตามประเภทและดัชนีของรายการ เช่น $func123 ซึ่งในภาพหน้าจอด้านบน วิธีนี้ช่วยทำให้สแต็กเทรซและการถอดแยกชิ้นส่วนที่อ่านง่ายขึ้นได้เล็กน้อย

เมื่อไม่มีข้อมูลประเภท การตรวจสอบค่าใดๆ นอกเหนือจากแบบพื้นฐานอาจทำได้ยาก เช่น ตัวชี้จะแสดงเป็นจำนวนเต็มปกติ โดยไม่สามารถรู้ได้ว่ามีสิ่งใดบ้างจัดเก็บไว้ในหน่วยความจำ

การตรวจสอบหน่วยความจำ

ก่อนหน้านี้คุณจะขยายได้เฉพาะออบเจ็กต์หน่วยความจำ WebAssembly ที่แสดงด้วย env.memory ในมุมมองขอบเขตเพื่อค้นหาไบต์แต่ละรายการ วิธีนี้ได้ผลในบางสถานการณ์ที่ไม่สำคัญ แต่ไม่สะดวกนักในการขยาย และไม่อนุญาตให้ตีความข้อมูลซ้ำในรูปแบบอื่นนอกเหนือจากค่าไบต์ เราได้เพิ่มคุณลักษณะใหม่เพื่อช่วยในเรื่องนี้ด้วย ซึ่งก็คือเครื่องมือตรวจสอบหน่วยความจำเชิงเส้น

หากคลิกขวาที่ env.memory คุณควรจะเห็นตัวเลือกใหม่ที่ชื่อว่า ตรวจสอบหน่วยความจำ ดังนี้

เมื่อคลิกแล้ว ระบบจะแสดงเครื่องมือตรวจสอบหน่วยความจำ ซึ่งคุณจะตรวจสอบหน่วยความจำ WebAssembly ในมุมมองเลขฐานสิบหกและ ASCII เพื่อไปยังที่อยู่ที่เจาะจง รวมถึงตีความข้อมูลในรูปแบบต่างๆ ได้ ดังนี้

สถานการณ์ขั้นสูงและคำเตือน

การทำโปรไฟล์โค้ด WebAssembly

เมื่อคุณเปิดเครื่องมือสำหรับนักพัฒนาเว็บ โค้ด WebAssembly จะ "ลดขั้น" เป็นเวอร์ชันที่ไม่ได้เพิ่มประสิทธิภาพเพื่อเปิดใช้การแก้ไขข้อบกพร่อง เวอร์ชันนี้ช้ากว่ามาก ซึ่งหมายความว่าคุณจะไม่สามารถอาศัย console.time, performance.now และวิธีการอื่นๆ ในการวัดความเร็วของโค้ดขณะที่เปิดเครื่องมือสำหรับนักพัฒนาเว็บอยู่ เนื่องจากตัวเลขที่คุณได้รับจะไม่ได้แสดงถึงประสิทธิภาพในชีวิตจริงเลย

แต่คุณควรใช้แผงประสิทธิภาพสำหรับเครื่องมือสำหรับนักพัฒนาเว็บ ซึ่งจะเรียกใช้โค้ดด้วยความเร็วสูงสุด และแสดงรายละเอียดเวลาในการทำงานในฟังก์ชันต่างๆ ดังนี้

หรืออีกวิธีคือ คุณสามารถเรียกใช้แอปพลิเคชันโดยปิดเครื่องมือสำหรับนักพัฒนาเว็บไป แล้วเปิดแอปพลิเคชันเมื่อเสร็จสิ้นเพื่อตรวจสอบคอนโซล

เราจะปรับปรุงสถานการณ์การสร้างโปรไฟล์ในอนาคต แต่สำหรับตอนนี้ โปรดระมัดระวัง หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับสถานการณ์การจัดลำดับของ WebAssembly โปรดดูเอกสารของเราที่ไปป์ไลน์การคอมไพล์ WebAssembly

การสร้างและการแก้ไขข้อบกพร่องในเครื่องอื่น (รวมถึง Docker / โฮสต์)

เมื่อสร้างใน Docker, เครื่องเสมือน หรือในเซิร์ฟเวอร์บิลด์ระยะไกล คุณอาจพบสถานการณ์ที่เส้นทางไปยังไฟล์ต้นฉบับที่ใช้ระหว่างการสร้างไม่ตรงกับเส้นทางในระบบไฟล์ของคุณเองที่เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ทำงานอยู่ ในกรณีนี้ ไฟล์จะแสดงในแผงแหล่งที่มาแต่โหลดไม่สำเร็จ

เพื่อแก้ไขปัญหานี้ เราได้นำฟังก์ชันการแมปเส้นทางมาใช้ในตัวเลือกส่วนขยาย C/C++ ซึ่งนำมาใช้เพื่อแมปเส้นทางที่กำหนดเองอีกครั้งและช่วยเครื่องมือสำหรับนักพัฒนาเว็บค้นหาแหล่งที่มาได้

ตัวอย่างเช่น หากโปรเจ็กต์ในเครื่องโฮสต์อยู่ภายใต้เส้นทาง C:\src\my_project แต่สร้างไว้ในคอนเทนเนอร์ Docker ซึ่งเส้นทางนั้นแสดงเป็น /mnt/c/src/my_project คุณสามารถแมปกลับใหม่ในระหว่างการแก้ไขข้อบกพร่องได้โดยระบุเส้นทางเหล่านั้นเป็นคำนำหน้า ดังนี้

คำนำหน้าที่ตรงกันรายการแรกคือ "wins" หากคุณคุ้นเคยกับโปรแกรมแก้ไขข้อบกพร่อง C++ อื่นๆ ตัวเลือกนี้จะคล้ายกับคำสั่ง set substitute-path ใน GDB หรือการตั้งค่า target.source-map ใน LLDB

การแก้ไขข้อบกพร่องของบิลด์ที่เพิ่มประสิทธิภาพ

เช่นเดียวกับภาษาอื่นๆ การแก้ไขข้อบกพร่องจะทำงานได้ดีที่สุดหากปิดใช้การเพิ่มประสิทธิภาพ การเพิ่มประสิทธิภาพอาจทำงานในหน้าต่างๆ กัน เรียงลำดับโค้ดใหม่ หรือนำส่วนต่างๆ ของโค้ดออกทั้งหมด ซึ่งทั้งหมดนี้จะมีโอกาสสร้างความสับสนให้กับโปรแกรมแก้ไขข้อบกพร่องและทำให้คุณในฐานะผู้ใช้ได้

หากคุณไม่มีปัญหากับการแก้ไขข้อบกพร่องที่จำกัดมากขึ้น และยังคงต้องการแก้ไขข้อบกพร่องของเวอร์ชันที่เพิ่มประสิทธิภาพ การเพิ่มประสิทธิภาพส่วนใหญ่ก็จะทำงานได้ตามที่คาดหวังไว้ ยกเว้นในหน้าฟังก์ชัน เราวางแผนที่จะจัดการกับปัญหาที่เหลือในอนาคต แต่ในตอนนี้ โปรดใช้ -fno-inline เพื่อปิดใช้เมื่อรวมเข้ากับการเพิ่มประสิทธิภาพระดับ -O เช่น

emcc -g temp.c -o temp.html \
     -O3 -fno-inline

การแยกข้อมูลการแก้ไขข้อบกพร่อง

ข้อมูลการแก้ไขข้อบกพร่องจะเก็บรายละเอียดมากมายเกี่ยวกับโค้ด ประเภท ตัวแปร ฟังก์ชัน ขอบเขต และตำแหน่งที่กำหนด รวมถึงตำแหน่งใดก็ตามที่อาจเป็นประโยชน์ต่อโปรแกรมแก้ไขข้อบกพร่อง ด้วยเหตุนี้ แท็กจึงมักจะมีขนาดใหญ่กว่าตัวโค้ด

หากต้องการเพิ่มความเร็วในการโหลดและรวบรวมโมดูล WebAssembly คุณอาจต้องแยกข้อมูลการแก้ไขข้อบกพร่องนี้ออกเป็นไฟล์ WebAssembly แยกต่างหาก หากต้องการดำเนินการใน Emscripten ให้ส่งแฟล็ก -gseparate-dwarf=… พร้อมชื่อไฟล์ที่ต้องการ:

emcc -g temp.c -o temp.html \
     -gseparate-dwarf=temp.debug.wasm

ในกรณีนี้ แอปพลิเคชันหลักจะจัดเก็บเฉพาะชื่อไฟล์ temp.debug.wasm และส่วนขยายตัวช่วยจะค้นหาและโหลดได้เมื่อคุณเปิดเครื่องมือสำหรับนักพัฒนาเว็บ

เมื่อผสานเข้ากับการเพิ่มประสิทธิภาพตามที่อธิบายไว้ข้างต้น คุณอาจใช้ฟีเจอร์นี้เพื่อจัดส่งบิลด์เวอร์ชันที่ใช้งานจริงที่เกือบมีประสิทธิภาพสูงสุดสำหรับแอปพลิเคชันของคุณ และแก้ไขข้อบกพร่องด้วยไฟล์ฝั่งในเครื่องในภายหลังได้ ในกรณีนี้ เราจะต้องลบล้าง URL ที่เก็บไว้เพื่อช่วยส่วนขยายค้นหาไฟล์ด้านข้างได้ เช่น

emcc -g temp.c -o temp.html \
     -O3 -fno-inline \
     -gseparate-dwarf=temp.debug.wasm \
     -s SEPARATE_DWARF_URL=file://[local path to temp.debug.wasm]

การดำเนินการต่อไป...

โอ้โห เป็นฟีเจอร์ใหม่ๆ เยอะมาก

การผสานรวมใหม่เหล่านั้นทำให้ Chrome DevTools กลายเป็นเครื่องมือแก้ไขข้อบกพร่องที่ทำงานได้จริงและทรงพลัง ไม่เพียงสำหรับ JavaScript เท่านั้น แต่ยังรวมถึงแอป C และ C++ ด้วย ทำให้ใช้แอปได้ง่ายขึ้นกว่าที่เคย มีเทคโนโลยีมากมายที่นำมาปรับใช้ในเว็บที่แชร์ข้ามแพลตฟอร์ม

อย่างไรก็ตาม การเดินทางของเรายังไม่สิ้นสุด สิ่งที่เราจะทำต่อไป มีดังต่อไปนี้

• ลบขอบที่หยาบๆ ในการแก้ไขข้อบกพร่อง
• เพิ่มการรองรับตัวจัดรูปแบบประเภทที่กำหนดเอง
• ดำเนินการปรับปรุงการทำโปรไฟล์สำหรับแอป WebAssembly
• เพิ่มการรองรับการครอบคลุมของโค้ดเพื่อให้ค้นหาโค้ดที่ไม่ได้ใช้ได้ง่ายขึ้น
• ปรับปรุงการรองรับนิพจน์ในการประเมินคอนโซล
• เพิ่มการรองรับภาษาอื่นๆ
• …และอีกมากมาย

ในระหว่างนี้ โปรดช่วยเราด้วยการลองใช้เวอร์ชันเบต้าปัจจุบันในโค้ดของคุณเอง และรายงานปัญหาที่พบไปยัง https://bugs.chromium.org/p/chromium/issues/entry?template=DevTools+issue

ดาวน์โหลดช่องตัวอย่าง

ลองใช้ Chrome Canary, Dev หรือเบต้าเป็นเบราว์เซอร์สำหรับการพัฒนาเริ่มต้น ตัวอย่างช่องทางเหล่านี้จะช่วยให้คุณสามารถเข้าถึงฟีเจอร์ล่าสุดของเครื่องมือสำหรับนักพัฒนาเว็บ ทดสอบ API แพลตฟอร์มเว็บที่ล้ำสมัย และค้นหาปัญหาในเว็บไซต์ก่อนที่ผู้ใช้จะทำงานได้

ติดต่อทีมเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

ใช้ตัวเลือกต่อไปนี้เพื่อพูดคุยเกี่ยวกับฟีเจอร์ใหม่ๆ และการเปลี่ยนแปลงในโพสต์หรือเรื่องอื่นๆ ที่เกี่ยวข้องกับเครื่องมือสำหรับนักพัฒนาเว็บ

• ส่งคำแนะนำหรือความคิดเห็นถึงเราผ่าน crbug.com
• รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บโดยใช้ตัวเลือกเพิ่มเติม     > ความช่วยเหลือ > รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บในเครื่องมือสำหรับนักพัฒนาเว็บ
• ทวีตที่ @ChromeDevTools
• แสดงความคิดเห็นเกี่ยวกับ "มีอะไรใหม่ในวิดีโอ YouTube สำหรับเครื่องมือสำหรับนักพัฒนาเว็บ" หรือเคล็ดลับเครื่องมือสำหรับนักพัฒนาเว็บวิดีโอ YouTube