[Bug python/11482] New: Side effect of set print address on python API

[Bug python/11482] New: Side effect of set print address on python API

[michel dot metzger at st dot com]

The GDB command set print address seems to have a side effect on the 
Frame.read_var() Python method (and maybe others).

Here is a simple example:

(gdb) set print address on
(gdb) python print len(str(gdb.selected_frame().read_var("argv")))
10
(gdb) set print address off
(gdb) python print len(str(gdb.selected_frame().read_var("argv")))
0 

i.e. the read_var() method does not return a valid Value when print address is off.

-- 
           Summary: Side effect of set print address on python API
           Product: gdb
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: python
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: michel dot metzger at st dot com
                CC: gdb-prs at sourceware dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686 athlon i386 GNU/Linux


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-04-14 17:05 -------
argv needs to be dereferenced:

(gdb) ptype argv
type = char **
(gdb) set print address off
(gdb) python print gdb.selected_frame().read_var("argv").dereference()
"/home/pmuldoon/simple"

The length you were seeing was the textual length of the address before
dereferencing:

(gdb) set print address on
(gdb) python print gdb.selected_frame().read_var("argv")
0x7fffffffe1a8
(gdb) python print len(str(gdb.selected_frame().read_var("argv")))
14

The address is printed as part of the Value's Python str() method. This is
because argv is a pointer to a pointer.  Does this conform with your view?


-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[michel dot metzger at st dot com]

------- Additional Comments From michel dot metzger at st dot com  2010-04-14 17:47 -------
I'm not trying to retrieve what is pointed by argv but the value of argv. I used
the str() function to retrieve the value of the pointer. But maybe there is a
better way to do that.

Anyway, I don't think the set print address off command should impact the
behavior of the python str() method.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-04-14 20:05 -------
str() is not being affected by 'set print address on'. str() is converting a
Python variable to a string.  But if there is nothing to convert there is
nothing to convert. ;)

Take these examples.  In this (your) case the string is the address itself:

(gdb) python print gdb.selected_frame().read_var("argv")
0x7fffffffe1a8
(gdb) python print len(str(gdb.selected_frame().read_var("argv")))
14

'0x7fffffffe1a8' is 14 characters long.  You get the address as a value because
of the type (char **). If you want what that points to you have to dereference
it.  So in this example, when you 'set print address off', you are telling GDB
not to print addresses. So in this case it would be:

(gdb) python print gdb.selected_frame().read_var("argv")

(gdb) python print len(str(gdb.selected_frame().read_var("argv")))
0

Because there is nothing to print in that case.  str() has nothing to work with.
You told GDB not to print addresses, and the value of char ** type is an
address. The Python scripting has to abide by the rules set down by GDB, and set
by the user through the 'set foo' commands.

So if the value of a read_var is an address should we print it regardless of
what the user told GDB to do? I think we should abide by the options set down at
this point.

There might be a case for read_var always dereferencing what it reads, but I'm
not keen on that.  IMO, everything is working as it should?




-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-04-14 20:21 -------
Oops I made a small error, so a correction. It's not the Python API that is
enforcing whether they abide by the rules, it is the GDB code itself. In
valprint a call is made to the language specific print code:

09	      ret = language->la_val_print (type, valaddr, embedded_offset, address,
(top-gdb) s
c_val_print (type=0xcdc3e0, valaddr=0xd01900 "\370\341\377\377\377\177", 
    embedded_offset=0, address=140737488347376, stream=0xcdcc20, recurse=0, 
    options=0x7fffffffd4f0) at ../../src/gdb/c-valprint.c:155

Which has a conditional:

276		  if (options->addressprint)
277		    fputs_filtered (paddress (gdbarch, addr), stream);

If addressprint is set to 0, as set by "set print address off" nothing will be
printed here and the function will return. So even though the Python value
contains the address, it will not be printed by GDB (regardless of whatever
Python tricks we could try)

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[michel dot metzger at st dot com]

------- Additional Comments From michel dot metzger at st dot com  2010-04-14 21:07 -------
I understand, but I still think that the user, with the python API, should still
be able to get the value of a pointer regardless of the state of set print
address. What if he doesn't want to print it? In my case I use it as an index in
an internal table.

Developers of new commands in python should make sure they follow the rules set
by commands like set print address.

I hope this clarify things :)

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-04-14 21:29 -------
Oh they can get the value of the pointer, store it, add to it .. manipulate it
in any way ... they just can't print it in GDB with: 'set print address off'

This is output from 7.1 with some of my comments:

(gdb) print argv
$1 = (char **) 0x7fffffffe1f8
(gdb) set print address off

(gdb) print argv
$2 = (char **) 

Ok with 'set print address off' we'll get the value (in the case the
pointer/address).

(gdb) python argv_var = gdb.selected_frame().read_var("argv")

We try to print it

(gdb) python print str(argv_var)

No luck, 'set print address' is off.

Turn 'set print address' back on:

(gdb) set print address on

(gdb) python print str(argv_var)
0x7fffffffe1f8

Aha there it is. The actual value or argv_var always is (in this case)
'0x7fffffffe1f8' -- argv_var always stores that. Just that in GDB when 'set
print address' is set to 'off', all addresses -- regardless of where they come
from are suppressed from being printed. They are still stored in the variable.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[tromey at redhat dot com]

------- Additional Comments From tromey at redhat dot com  2010-04-14 23:18 -------
(gdb) set print address off

(gdb) print argv
$2 = (char **) 


This is a generic gdb bug, maybe even a regression.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-04-14 23:31 -------
The manual says:

 "You can use @samp{set print address off} to eliminate all machine
 dependent displays from the @value{GDBN} interface.  For example, with
 @code{print address off}, you should get the same text for backtraces on
 all machines---whether or not they involve pointer arguments."

Sounds like this was intended design.


-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-04-14 23:32 -------
gdb 5.3 (2002) behaves the same.


-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[michel dot metzger at st dot com]

------- Additional Comments From michel dot metzger at st dot com  2010-04-15 14:35 -------
I perfectly understand how set print address works and what it's used for.
Let me explain with more details what I'm trying to achieve. Maybe I'm doing
this completely wrong.

I'm developing new commands to ease the debugging of applications developed
using component-oriented programming. I want to write a command that will print,
using the value of the "this" pointer, the actual name of the instance. 

To do that I have a table, in python, of all instances (more or less like OOP
instances), indexed with their location in memory. Since gdb.Value is not
hashable, so there is no way to use it directly as a key. So the solution I
implemented was to use the string representing the address as a key in my hashtable.

As you can see, I'm not trying to print any address, just use them internally in
the command implementation.

I hope this will makes things clearer.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-04-15 14:40 -------
To be clear, my comments (#8 and #9) were in response to "This is a generic gdb 
bug, maybe even a regression." only.


-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-04-15 16:23 -------
There are two things we can do here. Can you compose a testcase/reproducer in a
Python command where the "set print address on" is causing an issue in your
coding logic. Something simple will do.  That will probably help us to
understand the issue a little better.  

The second thing that comes to mind is why isn't gdb.Value hashable? Should it
be? If so, can we do it and is it desirable to do so? 


-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

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


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[tromey at redhat dot com]

------- Additional Comments From tromey at redhat dot com  2010-04-19 22:00 -------
(In reply to comment #12)

> The second thing that comes to mind is why isn't gdb.Value hashable? Should it
> be? If so, can we do it and is it desirable to do so? 

The problem is that the contents of struct value are mutable.
It isn't clear what you could hash on, except object identity.
Maybe that is good enough.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[michel dot metzger at st dot com]

------- Additional Comments From michel dot metzger at st dot com  2010-04-21 15:26 -------
Created an attachment (id=4745)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4745&action=view)
Small testcase illustrating the issue


-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[michel dot metzger at st dot com]

------- Additional Comments From michel dot metzger at st dot com  2010-04-21 15:27 -------
I attached a small testcase.

To run it:
make
gdb -x gdb.cmd

(tested on gdb 7.0.1 and python 2.6.4)

It is very close to what I'm actually doing. The map is populated from data
generated by our compiler instead of hard-coded variable names and component
names. The rest is conceptually identical.

As you can see, the command stops working after set print address is set to off.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]


------- Additional Comments From pmuldoon at redhat dot com  2010-05-06 13:15 -------
Created an attachment (id=4771)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4771&action=view)
Python Value Hash Patch

If making GDB values hash-able would fix the problem then I agree, lets see if
it can be done.  I did some research on object ids.

The Python documentation says this about object ID:

http://docs.python.org/library/functions.html

id(object)¶

    Return the “identity” of an object. This is an integer (or long integer)
which is guaranteed to be unique and constant for this object during its
lifetime. Two objects with non-overlapping lifetimes may have the same id()
value.

    CPython implementation detail: This is the address of the object.

The "Two objects with non-overlapping lifetimes may have the same id() value"
statement caused me concern. I guess they are saying that two objects can have
the same ID, but only once the previous has been destroyed.

However this seems to conflict with the data model narrative:

http://docs.python.org/reference/datamodel.html

"Every object has an identity, a type and a value. An object’s identity never
changes once it has been created; " (snip) "Objects are never explicitly
destroyed; however, when they become unreachable they may be
garbage-collected."

I'm not sure what that means in total, but I interpret it to mean that one
object will never have the same address as another garbage-collected object at
the same time.

As GDB values never go away either then I think object ID works for hashing.
Here is a draft patch with no documentation or tests.  I cannot call the
builtin id function, so I replicated what it does in the hash function (which
is basically return the address of the Python Object).

Here is the output with the patch, with a smoke test comparison to make sure
our patch mimics the id() function

(gdb) py v = gdb.Value(1)
(gdb) py print v.__hash__()
139903601340288
(gdb) py print id(v)
139903601340288
(gdb) p/x 139903601340288
$1 = 0x7f3dd875ef80

Tom what do you think?


-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

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


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[tromey at redhat dot com]

------- Additional Comments From tromey at redhat dot com  2010-05-12 20:21 -------
(In reply to comment #16)
 
> Tom what do you think?

I think we should go with identity hashing.
We can't do better, since some values are mutable.
In specific cases, python users can always write wrapper objects
with some other hash function.

The current patch (as we discussed on irc) is not ok, though, because
it needlessly creates a new object when computing the hash.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2010-05-14 11:11 -------
Subject: Bug 11482

CVSROOT:	/cvs/src
Module name:	src
Changes by:	pmuldoon@sourceware.org	2010-05-14 11:11:28

Modified files:
	gdb            : ChangeLog 
	gdb/python     : py-value.c 
	gdb/testsuite  : ChangeLog 
	gdb/testsuite/gdb.python: py-value.exp 

Log message:
	2010-05-14  Phil Muldoon  <pmuldoon@redhat.com>
	
	PR python/11482
	
	* python/py-value.c (valpy_hash): New function.
	(value_object_type): Register valpy_hash.
	
	2010-05-14  Phil Muldoon  <pmuldoon@redhat.com>
	
	PR python/11482
	
	* gdb.python/py-value.exp (test_value_hash): New function

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.11790&r2=1.11791
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-value.c.diff?cvsroot=src&r1=1.9&r2=1.10
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.2265&r2=1.2266
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.python/py-value.exp.diff?cvsroot=src&r1=1.8&r2=1.9



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at sourceware dot|pmuldoon at redhat dot com
                   |org                         |
             Status|NEW                         |ASSIGNED


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-05-17 09:22 -------
* Make GDB Values hashable

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2010-05-17 09:22 -------
We've checked in a patch to make GDB values.  Does this fix your problem Michel?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING
   Target Milestone|7.1                         |7.2


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[michel dot metzger at st dot com]

------- Additional Comments From michel dot metzger at st dot com  2010-05-19 14:57 -------
Created an attachment (id=4801)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4801&action=view)
testcase updated to use the Value object (with new hash method) as key 

to run the test:

make
gdb -x gdb.cmd test


-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[michel dot metzger at st dot com]

------- Additional Comments From michel dot metzger at st dot com  2010-05-19 14:59 -------
Thanks for the patch. Unfortunately I'm afraid it does work in my case.
>From what I understood the hash is based on the python Value object address. So
two different Value instances representing the same address in the program being
debugged will have two different hashes. In my case this is a problem since the
hash map is initialized with global variable addresses as key and accessed with
a function parameter's value. Thus, I have two different Value object and two
different hash codes. I uploaded a new testcase showing this:

http://sourceware.org/bugzilla/attachment.cgi?id=4801

Maybe we could use the pointer value as a hash code for Value object
representing pointers?

Another solution (probably more complex though) would be to provide a method to
get the actual value of a Value object. I don't know if it makes sense...

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[tromey at redhat dot com]

------- Additional Comments From tromey at redhat dot com  2010-05-19 23:01 -------
(In reply to comment #22)
> Thanks for the patch. Unfortunately I'm afraid it does work in my case.

> Maybe we could use the pointer value as a hash code for Value object
> representing pointers?

Many values have mutable contents.  So we can't really hash on the contents.
We could hash on the address, but not all values have addresses, and,
bizarrely, I think you can have values with the same address but different
contents (if they were read from inferior memory at different times).

This is why we ended up going with identity hashing.

I realize this is not ideal.  In many cases the above considerations do not
apply.  However, it seems to me that in a specialized case you could pretty
easily write a hashable facade that has whatever hash and equality methods
you like.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[michel dot metzger at st dot com]

------- Additional Comments From michel dot metzger at st dot com  2010-05-20 14:37 -------
(In reply to comment #23)
> (In reply to comment #22)
> > Thanks for the patch. Unfortunately I'm afraid it does work in my case.
> 
> > Maybe we could use the pointer value as a hash code for Value object
> > representing pointers?
> 
> Many values have mutable contents.  So we can't really hash on the contents.
> We could hash on the address, but not all values have addresses, and,
> bizarrely, I think you can have values with the same address but different
> contents (if they were read from inferior memory at different times).
> 
> This is why we ended up going with identity hashing.
> 
> I realize this is not ideal.  In many cases the above considerations do not
> apply.  However, it seems to me that in a specialized case you could pretty
> easily write a hashable facade that has whatever hash and equality methods
> you like.

I understand.

Regarding the hashable facade, could you give me a hint? I would have done that
from the start but I don't see how I can write a hash function if I cannot
access the underlying value from Python. E.g., get the value of a pointer as an
integer in python. That's why I ended up using the string representation of the
pointer.

-- 


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[tromey at redhat dot com]

------- Additional Comments From tromey at redhat dot com  2010-06-30 17:37 -------
(In reply to comment #24)

> Regarding the hashable facade, could you give me a hint? I would have done that
> from the start but I don't see how I can write a hash function if I cannot
> access the underlying value from Python. E.g., get the value of a pointer as an
> integer in python. That's why I ended up using the string representation of the
> pointer.

Oops, sorry about this.  I forgot to reply earlier :-(

If you know that you care only about pointers, you can get them as Python
values using 'long':

(gdb) p (void*)0
$1 = (void *) 0x0
(gdb) python x = gdb.history(1)
(gdb) python print x
0x0
(gdb) python print long(x)
0

I do think we need some way to convert a Value to its underlying bits,
either by letting Python treat Value as a buffer, or by having a method
to return a buffer.




-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|0000-00-00 00:00:00         |2010-06-30 17:37:54
               date|                            |


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

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug python/11482] Side effect of set print address on python API

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

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

--- Comment #26 from Hannes Domani <ssbssa at sourceware dot org> ---
Maybe not exactly what was wanted here, but since [1] it's possible to
explicitly enable or disable printing of the address in Value.format_string, no
matter how it's set with 'set print address'.

So to always enable the address, use Value.format_string(address=True), like:

(gdb) py print(gdb.parse_and_eval("argv"))
0x5a1f90
(gdb) py print(gdb.parse_and_eval("argv").format_string())
0x5a1f90
(gdb) set print address off
(gdb) py print(gdb.parse_and_eval("argv").format_string())

(gdb) py print(gdb.parse_and_eval("argv").format_string(address=True))
0x5a1f90


[1]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=4aea001fd84a05f1e552c5dea1025e3f62dd2d7e

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

[Bug python/11482] Side effect of set print address on python API

[ssbssa at sourceware dot org]

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

--- Comment #27 from Hannes Domani <ssbssa at sourceware dot org> ---
(In reply to Tom Tromey from comment #25)
> I do think we need some way to convert a Value to its underlying bits,
> either by letting Python treat Value as a buffer, or by having a method
> to return a buffer.

This is now possible with gdb.Value.bytes.

Plus the aforementioned methods to get either a pointer value with long/int, or
a string representation regardless of 'set print address' with
'Value.format_string(address=True)', is this enough to close this ticket?

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