From 93bb1ebf7f8d61b7995fa6386f7a01681d524fa1 Mon Sep 17 00:00:00 2001 From: Tom de Vries Date: Mon, 7 Apr 2025 22:40:04 +0200 Subject: [gdb/cli] Use debug info language to pick pygments lexer Consider the following scenario: ... $ cat hello int main (void) { printf ("hello\n"); return 0; } $ gcc -x c hello -g $ gdb -q -iex "maint set gnu-source-highlight enabled off" a.out Reading symbols from a.out... (gdb) start Temporary breakpoint 1 at 0x4005db: file hello, line 6. Starting program: /data/vries/gdb/a.out [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Temporary breakpoint 1, main () at hello:6 6 printf ("hello\n"); ... This doesn't produce highlighting for line 6, because: - pygments is used for highlighting instead of source-highlight, and - pygments guesses the language for highlighting only based on the filename, which in this case doesn't give a clue. Fix this by: - adding a language parameter to the extension_language_ops.colorize interface, - passing the language as found in the debug info, and - using it in gdb.styling.colorize to pick the pygments lexer. The new test-case gdb.python/py-source-styling-2.exp excercises a slightly different scenario: it compiles a c++ file with a .c extension, and checks that c++ highlighting is done instead of c highlighting. Tested on x86_64-linux. Approved-By: Tom Tromey PR cli/30966 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966 --- gdb/python/python.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) (limited to 'gdb/python/python.c') diff --git a/gdb/python/python.c b/gdb/python/python.c index 2aaa30c..e32b776 100644 --- a/gdb/python/python.c +++ b/gdb/python/python.c @@ -128,7 +128,8 @@ static bool gdbpy_check_quit_flag (const struct extension_language_defn *); static enum ext_lang_rc gdbpy_before_prompt_hook (const struct extension_language_defn *, const char *current_gdb_prompt); static std::optional gdbpy_colorize - (const std::string &filename, const std::string &contents); + (const std::string &filename, const std::string &contents, + enum language lang); static std::optional gdbpy_colorize_disasm (const std::string &content, gdbarch *gdbarch); static ext_lang_missing_file_result gdbpy_handle_missing_debuginfo @@ -1295,7 +1296,8 @@ gdbpy_before_prompt_hook (const struct extension_language_defn *extlang, /* This is the extension_language_ops.colorize "method". */ static std::optional -gdbpy_colorize (const std::string &filename, const std::string &contents) +gdbpy_colorize (const std::string &filename, const std::string &contents, + enum language lang) { if (!gdb_python_initialized) return {}; @@ -1329,6 +1331,13 @@ gdbpy_colorize (const std::string &filename, const std::string &contents) return {}; } + gdbpy_ref<> lang_arg (PyUnicode_FromString (language_str (lang))); + if (lang_arg == nullptr) + { + gdbpy_print_stack (); + return {}; + } + /* The pygments library, which is what we currently use for applying styling, is happy to take input as a bytes object, and to figure out the encoding for itself. This removes the need for us to figure out @@ -1349,6 +1358,7 @@ gdbpy_colorize (const std::string &filename, const std::string &contents) gdbpy_ref<> result (PyObject_CallFunctionObjArgs (hook.get (), fname_arg.get (), contents_arg.get (), + lang_arg.get (), nullptr)); if (result == nullptr) { -- cgit v1.1