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

Ingvar Stepanyan

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

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

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

เราได้แสดงให้เห็นถึงการสนับสนุน ก้าวเบื้องต้นและพูดคุยเกี่ยวกับโอกาส การใช้ข้อมูล 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);
}

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

emcc -g temp.c -o temp.html

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

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

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

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

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

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

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

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

การสนับสนุนประเภทริชมีเดีย

มาดูตัวอย่างที่ซับซ้อนขึ้นเพื่อแสดงตัวอย่างกันดีกว่า ช่วงเวลานี้ เราจะวาดแฟร็กทัล 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++ ไลบรารีมาตรฐาน

ผมจะคอมไพล์ด้วย Flag -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++ หรือขั้นตอน ตัวแปรอื่นๆ ก็เปลี่ยนแปลงเช่นกัน:

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

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

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

เรากลับมาที่การแก้ไขข้อบกพร่อง WebAssembly แบบข้อมูลดิบ

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

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

ก่อนอื่น หากคุณเคยใช้การแก้ไขข้อบกพร่อง 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 คุณสามารถแมปใหม่ได้ กลับมาในระหว่างการแก้ไขข้อบกพร่องด้วยการระบุเส้นทางเหล่านั้นเป็นคำนำหน้า ดังนี้

คำนำหน้าที่ตรงกันรายการแรก "ชนะ" หากคุณคุ้นเคยกับ 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 ให้ส่ง Flag -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 DevTools

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

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