Go to file
Andrew Burgess 4cbe4ca5da gdb: add support for disassembler styling using libopcodes
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".
2022-07-11 12:02:54 +01:00
bfd Automatic date update in version.in 2022-07-11 00:00:24 +00:00
binutils Regenerate with automake-1.15.1 2022-07-09 20:10:47 +09:30
config Add markers for 2.39 branch 2022-07-08 10:41:07 +01:00
contrib
cpu Add markers for 2.39 branch 2022-07-08 10:41:07 +01:00
elfcpp Add markers for 2.39 branch 2022-07-08 10:41:07 +01:00
etc
gas gas: tc-tic54x.c hash tables 2022-07-09 21:48:02 +09:30
gdb gdb: add support for disassembler styling using libopcodes 2022-07-11 12:02:54 +01:00
gdbserver gdbserver: LoongArch: Add orig_a0 processing 2022-07-10 17:27:55 +08:00
gdbsupport [gdb] Block SIGTERM in worker threads 2022-06-30 13:31:06 +02:00
gnulib gnulib: update to bd11400942d6 2022-05-02 10:54:19 -04:00
gold Update version to 2.39.50 and regenerate files 2022-07-08 11:19:44 +01:00
gprof Regenerate with automake-1.15.1 2022-07-09 20:10:47 +09:30
gprofng Regenerate with automake-1.15.1 2022-07-09 20:10:47 +09:30
include Add markers for 2.39 branch 2022-07-08 10:41:07 +01:00
intl
ld Fix regeneration of ld configure and makefiles 2022-07-08 12:41:48 +01:00
libbacktrace
libctf Add markers for 2.39 branch 2022-07-08 10:41:07 +01:00
libdecnumber Merge config/ changes from GCC, to enable DFP on AArch64 2022-05-24 10:47:29 +01:00
libiberty Add markers for 2.39 branch 2022-07-08 10:41:07 +01:00
opcodes Regenerate with automake-1.15.1 2022-07-09 20:10:47 +09:30
readline gdb/readline: fix extra 'quit' message problem 2022-05-07 10:49:27 +01:00
sim sim: fix BFD_VMA format arguments on 32-bit hosts [PR gdb/29184] 2022-06-15 23:12:56 +01:00
texinfo
zlib Regenerate with automake-1.15.1 2022-07-09 20:10:47 +09:30
.cvsignore
.editorconfig
.gitattributes
.gitignore
ar-lib
ChangeLog Add markers for 2.39 branch 2022-07-08 10:41:07 +01:00
compile
config-ml.in
config.guess
config.rpath
config.sub
configure [gdb/build] Fix build breaker with --enable-shared 2022-06-27 15:36:19 +02:00
configure.ac [gdb/build] Fix build breaker with --enable-shared 2022-06-27 15:36:19 +02:00
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.