This repository has been archived by the owner. It is now read-only.

Rework v8dbg constants support #4289

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants

Rework v8 debug constants support, to allow GDB, SystemTap and DTrace to use a common source for debug constants, by using a common header file which defines list macros which can be used to generate definitions of these constants in several different formats.

I've left in examples for generating a struct, an array + an enum, and the global definitions which are used currently.
Tested with both the struct and array + enum options, using GDB and SystemTap scripts.

Changes:

- gen-postmortem-metadata.py: split off debug-support.h
  Convert debug constants to a list macro, and make the
  header file not depend on any other headers.
  This allows for easy preprocessing / parsing / inclusion.
  Define macros for easy generation of a struct or an array of
  debug constants, which can be accesses by any of GDB, SystemTap
  and DTrace scripts.
- debug-support.cc: Add __v8dbg_init(), to be called when
  statically linking to libv8. Otherwise, the linker ignores
  debug-support.o, and no debug constants will be available in the
  final binary.
- v8.cc: Add call to __v8dbg_init(). This should force the linker
  to include debug-support.o when statically linking libv8.
  Also, scripts should capture the debug constants while executing
  a probe on this function and not hardcode them, because the
  constants are essentially process-local (multiple processes,
  statically linked binaries linked with different libv8 versions
  could be active on the same system.)

Because this concerns V8 more than Node specifically, I would like to invite @bnoordhuis o have a look at this.
Any comments or suggestions are very welcome.

Rework v8 debug constants support
- gen-postmortem-metadata.py: split off debug-support.h
  Convert debug constants to a list macro, and make the
  header file not depend on any other headers.
  This allows for easy preprocessing / parsing / inclusion.
  Define macros for easy generation of a struct or an array of
  debug constants, which can be accesses by any of GDB, SystemTap
  and DTrace scripts.
- debug-support.cc: Add __v8dbg_init(), to be called when
  statically linking to libv8. Otherwise, the linker ignores
  debug-support.o, and no debug constants will be available in the
  final binary.
- v8.cc: Add call to __v8dbg_init(). This should force the linker
  to include debug-support.o when statically linking libv8.
  Also, scripts should capture the debug constants while executing
  a probe on this function and not hardcode them, because the
  constants are essentially process-local (multiple processes,
  statically linked binaries linked with different libv8 versions
  could be active on the same system.)
- common.gypi / v8.gyp: Add debug-support.h, define
  POSTMORTEM_SUPPORT

To test with GDB

$ gdb out/Debug/node
p v8dbg

To test with SystemTap:

# stap -v -e 'probe process.function("__v8dbg_init") { print($v8dbg$) }'

(yes, the seemingly superfluous parameter to __v8dbg_init() is a trick to make the constants easily available to stap, no need to specify @var("v8dbg@file.cc")->something)

Todo: change v8ustack.d to use the struct from debug-support.h, but that needs testing by someone with access to DTrace.

I'm currently working on a toy ustack helper for node using SystemTap. It may be of some use, but until SystemTap grows its own ustack helper support, it might derail when naive stack unwinding fails.

Can one of the admins verify this patch?

Hi, this work should be submitted upstream for v8, if you'd like some guidance on that please let me know. Thanks!

@tjfontaine tjfontaine closed this Feb 18, 2014

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.