mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-26 13:56:22 +08:00
08f406e9a1
Now that the disassembler has two different strategies for laying out the opcode bytes of an instruction (see /r vs /b for the disassemble command), I wanted to add support for this to the MI disassemble command. Currently the -data-disassemble command takes a single 'mode' value, which currently has 6 different values (0 -> 5), 3 of these modes relate to opcode display. So, clearly I should just add an additional 3 modes to handle the new opcode format, right? No, I didn't think that was a great idea either. So, I wonder, could I adjust the -data-disassemble command in a backward compatible way, that would allow GDB to move away from using the mode value altogether? I think we can. In this commit, I propose adding two new options to -data-disassemble, these are: --opcodes none|bytes|display --source Additionally, I will make the mode optional, and default to mode 0 if no mode value is given. Mode 0 is the simplest, no source code, no opcodes disassembly mode. The two new options are only valid for mode 0, if they are used with any other mode then an error is thrown. The --opcodes option can add opcodes to the result, with 'bytes' being equivalent to 'disassemble /b' and 'display' being 'disassemble /r'. The --source option will enable the /s style source code display, this is equivalent to modes 4 and 5. There is no way, using the new command options to get the now deprecated /m style source code display, that is mode 1 and 3. My hope is that new users of the MI will not use the mode at all, and instead will just use the new options to achieve the output they need. Existing MI users can continue to use the mode, and will not need to be updated to use the new options.
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.