aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-progspace.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2025-10-05 18:51:12 +0100
committerAndrew Burgess <aburgess@redhat.com>2025-10-07 16:35:44 +0100
commit01040a24d953136b7b3f4b17e0f6b3489acb7199 (patch)
treeec62337b7ca36cfde80425688dd4cb7ee5e74499 /gdb/python/py-progspace.c
parent48b5669c2e26debe49491ecf6e20e82ccf28c15b (diff)
downloadbinutils-01040a24d953136b7b3f4b17e0f6b3489acb7199.zip
binutils-01040a24d953136b7b3f4b17e0f6b3489acb7199.tar.gz
binutils-01040a24d953136b7b3f4b17e0f6b3489acb7199.tar.bz2
gdb/python: make use of gdb.Style for shipped Python commands
With the recent addition of the gdb.Style Python API, this commit goes through the gdb.Command sub-classes which we ship with GDB and adds some styling support. This adds 'title' style in a couple of places where we layout tables. And uses 'filename' style where we are printing filenames. While I was making these changes I've made a couple of related fixes. In 'info frame-filter', 'info missing-objfile-handlers', 'info pretty-printer', and 'info xmethod', we would sometimes print the gdb.Progspace.filename unconditionally, even though this field can sometimes be None. To better handle this case, I now check for None, and print '<no-file>' instead. We already printed that same string for the program space name in at least one other case, so this change makes things a little more consistent. I don't format the '<no-file>' string with the filename style, only if we have an actual filename does the string get formatted. The other fix I made was in 'maint info python-disassemblers'. Here I've added an extra space between the two columns in the output table. The two columns are 'Architecture' and 'Disassembler Name'. Given that one column contains a white space, it was rather confusing having a single space between columns. Luckily the tests don't depend on a single space, so nothing needs updating for this change. Additionally, in 'info frame-filter' I've updated the exception handling to use the gdb.warning function, rather than just printing a line of output. This means that should this case occur we get the neat little emoji. We have no tests that trigger this warning, and I couldn't figure out how to write one. In this end, I just hacked the Python code to raise an exception and checked the output looked reasonable. I suspect this warning might be a hard one to trigger! Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/python/py-progspace.c')
0 files changed, 0 insertions, 0 deletions