Conversion of gdb parameters to python is not always correct. Here's an example: bash$ gdb [...] (gdb) show endian The target endianness is set automatically (currently little endian) (gdb) python print gdb.parameter("endian") (gdb) i.e. the value is "" Explicitly setting the value to "auto" then yields a better result. (gdb) set endian auto The target endianness is set automatically (currently little endian) (gdb) python print gdb.parameter("endian") auto Plus it would be useful to see the actual endianness from python, instead of having to watch for and handle "auto".
I think the problem is that there is no generic way to retrieve an "auto" parameter's current value in gdb. The C code usually just uses the appropriate logic at the appropriate point, and the show functions are all hard-coded too. One clean solution would be to add another method to the set/show classes.
The result for 'endian' is "" specifically because the variable isn't initialized in gdb -- it defaults to nullptr. This started causing a crash at some point. I have a fix for the crash but not for the larger issue of having a getter that un-auto-fies parameters.
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dedb7102b3b35f789fd5c140fe01917eaeae2853 commit dedb7102b3b35f789fd5c140fe01917eaeae2853 Author: Tom Tromey <tromey@adacore.com> Date: Tue Jan 4 08:52:40 2022 -0700 Fix another crash with gdb parameters in Python While looking into the language-capturing issue, I found another way to crash gdb using parameters from Python: (gdb) python print(gdb.parameter('endian')) (This is related to PR python/12188, though this patch isn't going to fix what that bug is really about.) The problem here is that the global variable that underlies the "endian" parameter is initialized to NULL. However, that's not a valid value for an "enum" set/show parameter. My understanding is that, in gdb, an "enum" parameter's underlying variable must have a value that is "==" (not just strcmp-equal) to one of the values coming from the enum array. This invariant is relied on in various places. I started this patch by fixing the problem with "endian". Then I added some assertions to add_setshow_enum_cmd to try to catch other problems of the same type. This patch fixes all the problems that I found. I also looked at all the calls to add_setshow_enum_cmd to ensure that they were all included in the gdb I tested. I think they are: there are no calls in nat-* files, or in remote-sim.c; and I was trying a build with all targets, Python, and Guile enabled. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12188
As an alternative, should it be possible to get the endianness from a gdb.Architecture? Since that's basically what show_endian does when set to 'auto'.
I think the ideal would be for "auto" parameters to provide a method to get the current true value, so that Python scripts can find out "what gdb really thinks" without having to reimplement the logic by hand. It's kind of a pain to go through them all, though, so nobody has tried.