mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-27 14:39:09 +08:00

In passing I noticed that the gdb.tui/tui-layout.exp test script was a little strange, it tests the layout command multiple times, but never sets up our ANSI terminal emulator, so every layout command fails with a message about the terminal lacking the required abilities. It turns out that this was caused by this commit: commit 9162a27c5f5828240b53379d735679e2a69a9f41 Date: Tue Nov 13 11:59:03 2018 -0700 Change gdb test suite's TERM setting This was when we changed the testsuite to set the TERM environment variable to "dumb" by default. After this, any tui test that didn't set the terminal mode back to 'ansi' would fail to activate tui mode. For the tui-layout.exp test it just so happens that the test patterns are generic enough that the test continued to pass, even after this change. In this commit I have updated the test so we now check the layout command both with a 'dumb' terminal and with the 'ansi' terminal. When testing with the 'ansi' terminal, I have some limited validation that GDB correctly entered tui mode. I figured that it is probably worth having at least one test in the test suite that deliberately tries to enter tui mode in a dumb terminal, it would be sad if we one day managed to break GDB such that this caused a crash, and never noticed.
…
…
…
…
…
…
…
…
…
…
…
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.
Description
Languages
C
51.8%
Makefile
22.4%
Assembly
12.3%
C++
6%
Roff
1.4%
Other
5.4%