mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-21 04:42:53 +08:00
4cbe4ca5da
This commit extends GDB to make use of libopcodes styling support where available, currently this is just i386 based architectures, and RISC-V. For architectures that don't support styling using libopcodes GDB will fall back to using the Python Pygments package, when the package is available. The new libopcodes based styling has the disassembler identify parts of the disassembled instruction, e.g. registers, immediates, mnemonics, etc, and can style these components differently. Additionally, as the styling is now done in GDB we can add settings to allow the user to configure which colours are used right from the GDB CLI. There's some new maintenance commands: maintenance set libopcodes-styling enabled on|off maintenance show libopcodes-styling These can be used to manually disable use of libopcodes styling. This is a maintenance command as it's not anticipated that a user should need to do this. But, this could be useful for testing, or, in some rare cases, a user might want to override the Python hook used for disassembler styling, and then disable libopcode styling so that GDB falls back to using Python. Right now I would consider this second use case a rare situation, which is why I think a maintenance command is appropriate. When libopcodes is being used for styling then the user can make use of the following new styles: set/show style disassembler comment set/show style disassembler immediate set/show style disassembler mnemonic set/show style disassembler register The disassembler also makes use of the 'address' and 'function' styles to style some parts of the disassembler output. I have also added the following aliases though: set/show style disassembler address set/show style disassembler symbol these are aliases for: set/show style address set/show style function respectively, and exist to make it easier for users to discover disassembler related style settings. The 'address' style is used to style numeric addresses in the disassembler output, while the 'symbol' or 'function' style is used to style the names of symbols in disassembler output. As not every architecture supports libopcodes styling, the maintenance setting 'libopcodes-styling enabled' has an "auto-off" type behaviour. Consider this GDB session: (gdb) show architecture The target architecture is set to "auto" (currently "i386:x86-64"). (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "on". the setting defaults to "on" for architectures that support libopcodes based styling. (gdb) set architecture sparc The target architecture is set to "sparc". (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "off" (not supported on architecture "sparc") the setting will show as "off" if the user switches to an architecture that doesn't support libopcodes styling. The underlying setting is still "on" at this point though, if the user switches back to i386:x86-64 then the setting would go back to being "on". (gdb) maintenance set libopcodes-styling enabled off (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "off". now the setting is "off" for everyone, even if the user switches back to i386:x86-64 the setting will still show as "off". (gdb) maintenance set libopcodes-styling enabled on Use of libopcodes styling not supported on architecture "sparc". (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "off". attempting to switch the setting "on" for an unsupported architecture will give an error, and the setting will remain "off". (gdb) set architecture auto The target architecture is set to "auto" (currently "i386:x86-64"). (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "off". (gdb) maintenance set libopcodes-styling enabled on (gdb) maintenance show libopcodes-styling enabled Use of libopcodes styling support is "on". the user will need to switch back to a supported architecture before they can one again turn this setting "on". |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gdbserver | ||
gdbsupport | ||
gnulib | ||
gold | ||
gprof | ||
gprofng | ||
include | ||
intl | ||
ld | ||
libbacktrace | ||
libctf | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
ar-lib | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
multilib.am | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
test-driver | ||
ylwrap |
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.