Andrew Burgess b3b0595ff6 gdb/testsuite: extend gdb.tui/tui-layout.exp test script
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.
2023-01-25 10:33:22 +00:00
2023-01-25 00:00:11 +00:00
2023-01-04 13:23:54 +10:30
2020-09-25 10:24:44 -04:00
2022-12-31 12:05:28 +00:00
2023-01-18 11:12:20 -07:00
2022-09-28 13:37:31 +09:30
2022-07-09 20:10:47 +09:30
2022-01-28 08:25:42 -05:00
2022-12-31 12:05:28 +00:00

		   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
Unofficial mirror of sourceware binutils-gdb repository. Updated daily.
Readme 780 MiB
Languages
C 51.8%
Makefile 22.4%
Assembly 12.3%
C++ 6%
Roff 1.4%
Other 5.4%