aboutsummaryrefslogtreecommitdiff
path: root/bfd/elflink.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2016-01-19 11:07:07 -0500
committerSimon Marchi <simon.marchi@ericsson.com>2016-01-19 11:07:07 -0500
commit10e3ed9029dc0b6eafcd991d9f292fc079f80cf5 (patch)
tree90471041d197089071fe50eb448de4a6a4354559 /bfd/elflink.c
parent41d1845edace3cf5dabd0aa7fa376b801fd5f675 (diff)
downloadgdb-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