A kernel debugger in Python: drgn

Posted Jun 1, 2019 7:10 UTC (Sat) by togga (subscriber, #53103)
In reply to: A kernel debugger in Python: drgn by vbabka
Parent article: A kernel debugger in Python: drgn

I can agree that going to plain text and back is bad but putting the logic in Python is even worse as Python is an old slow scripting language which will quickly limit your use-cases and make the whole system complex and heavy (read bloated). If you put the logic in a clean library it'll be reusable from both scripting languages (C++ could be one of them nowadays) and tools with less overhead like live-monitoring.

to post comments

A kernel debugger in Python: drgn

Posted Jun 1, 2019 11:45 UTC (Sat) by jeffm (subscriber, #29341) [Link] (3 responses)

The idea is to make it quickly extensible for both infrastructure and one-off analysis tools. Doing it a compiled language, especially one like C/C++, throws that out the window. Debugging a python script raising exceptions and terminating is a whole lot nicer than debugging a seg fault before you can start the work that was the real purpose of using the tool.

As long as the fault isn’t in the core code, failing scripts can be run repeatedly without restarting the debugger.

A kernel debugger in Python: drgn

Posted Jun 1, 2019 12:32 UTC (Sat) by jeffm (subscriber, #29341) [Link] (1 responses)

Also, the heavy lifting in both crash-python and drgn is C/C++ code already. GDB and libkdumpfile for the former and libdrgn for the latter.

A kernel debugger in Python: drgn

Posted Jun 2, 2019 21:26 UTC (Sun) by togga (subscriber, #53103) [Link]

Yes. DRGN seems to be a healthy mix. I didn't question that, I just argued against your statement to put all logic in python.

A kernel debugger in Python: drgn

Posted Jun 2, 2019 18:33 UTC (Sun) by togga (subscriber, #53103) [Link]

That might be the case 5 years ago, today the "two language problem" is basically solved, and tomorrow the scene will shift even further. I wouldn't call the debug-logic we're discussing here a "one-off". There are lots of synergies to be had between "infrastructure" and "analysis", these can easily end up in simulations, tests, live-monitoring or just reusing some code for different purposes in several places etc.

For real "one-off" things (fire and forget, no reuse) the discussion is pretty much pointless as you could use anything at hand to get from A to B which probably ends up in "it depends on multiple factors".

>> Doing it a compiled language, especially one like C/C++, throws that out the window."

Language and runtime environments are different things. C/C++ itself throws nothing out the window:
[cling]$ #include <stdexcept>
[cling]$ throw std::runtime_error("no segfault here")
>>> Caught a std::exception!
>>> no segfault here
[cling]$ auto x = (int *)nullptr
(int *) nullptr
[cling]$ auto no_segfault_here_either = *x
input_line_7:2:34: warning: null passed to a callee that requires a non-null argument [-Wnonnull]
auto no_segfault_here_either = *x
^

"Debugging a python script raising exceptions and terminating is a whole lot nicer than debugging a seg fault before you can start the work that was the real purpose of using the tool."

What you also get with Python is:
* one layer of complexity having to wrap/convert everything between "infrastructure world" and "script world"
* code very hard to reuse elsewhere, doesn't scale very well (GIL still there for instance) and brings a lots of baggage, especially a "forced" runtime environment

When your get stuck in above constraints or a Python encode/decode-hell you may have to chew and swallow that "lot nicer" statement and it won't be tasty (been there multiple times). Python has not moved away from the "scripting" corner, rather sunken in deeper, whereas other languages is moving in other directions. Everything is evolving (changing) rapidly though.