[Bug python/12188] New: python gdb.parameter("endian") is ""

[Bug python/12188] New: python gdb.parameter("endian") is ""

[dje at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12188

           Summary: python gdb.parameter("endian") is ""
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: python
        AssignedTo: unassigned@sourceware.org
        ReportedBy: dje@google.com


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".

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug python/12188] python gdb.parameter("endian") is ""

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12188

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #1 from Tom Tromey <tromey at redhat dot com> 2011-02-04 20:48:03 UTC ---
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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug python/12188] python gdb.parameter("endian") is ""

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12188

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12188] python gdb.parameter("endian") is ""

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12188

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12188] python gdb.parameter("endian") is ""

[ssbssa at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12188

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

--- Comment #4 from Hannes Domani <ssbssa at sourceware dot org> ---
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'.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug python/12188] python gdb.parameter("endian") is ""

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=12188

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.