diff options
author | Simon Marchi <simon.marchi@polymtl.ca> | 2016-01-19 11:07:07 -0500 |
---|---|---|
committer | Simon Marchi <simon.marchi@ericsson.com> | 2016-01-19 11:07:07 -0500 |
commit | 10e3ed9029dc0b6eafcd991d9f292fc079f80cf5 (patch) | |
tree | 90471041d197089071fe50eb448de4a6a4354559 /bfd/elflink.c | |
parent | 41d1845edace3cf5dabd0aa7fa376b801fd5f675 (diff) | |
download | gdb-10e3ed9029dc0b6eafcd991d9f292fc079f80cf5.zip gdb-10e3ed9029dc0b6eafcd991d9f292fc079f80cf5.tar.gz gdb-10e3ed9029dc0b6eafcd991d9f292fc079f80cf5.tar.bz2 |
Fix enum flag with Python 3
Using Python 3.5 (I assume it's the same with 3.4 and lower, but I didn't
test), I see this:
print (enum flag_enum) (FLAG_1)^M
Python Exception <class 'TypeError'> %x format: an integer is required, not gdb.Value: ^M
$7 = ^M
(gdb) FAIL: gdb.python/py-pp-maint.exp: print FLAG_1
Apparently, this idiom, where v is a gdb.Value, was possible with Python 2,
but not with Python 3:
'%x' % v
In Python 2, it would automatically get converted to an integer. To solve
it, I simply added wrapped v in a call to int().
'%x' % int(v)
In Python 2, the int type is implemented with a "long" in C, so on x86-32 it's
32-bits. I was worried that doing int(v) would truncate the value and give
wrong results for enum values > 32-bits. However, the int type != the int
function. The int function does the right thing, selecting the right integer
type for the given value. I tested with large enum values on x86-32 and
Python 2, and everything works as expected.
gdb/ChangeLog:
* python/lib/gdb/printing.py (_EnumInstance.to_string): Explicitly
convert gdb.Value to integer type using int().
Diffstat (limited to 'bfd/elflink.c')
0 files changed, 0 insertions, 0 deletions