mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-19 09:14:14 +08:00
a4f8f29027
When an assert triggers in tui mode the output is not great, the internal backtrace that is generated is printed directly to the file descriptor for gdb_stderr, and, as a result, does not currently format itself correctly - the output uses only '\n' at the end of each line, and so, when the terminal is in raw mode, the cursor does not return to the start of each line after the '\n'. This is mostly fixable, we could update bt-utils.c to use '\r\n' instead of just '\n', and this would fix most of the problems. The one we can't easily fix is if/when GDB is built to use execinfo instead of libbacktrace, in this case we use backtrace_symbols_fd to print the symbols, and this function only uses '\n' as the line terminator. Fixing this would require switching to backtrace_symbols, but that API uses malloc, which is something we're trying to avoid (this code is called when GDB hits an error, so ideally we don't want to rely on malloc). However, the execinfo code is only used when libbacktrace is not available (or the user specifically disables libbacktrace) so maybe we can ignore that problem... ... but there is another problem. When the backtrace is printed in raw mode, it is possible that the backtrace fills the screen. With the terminal in raw mode we don't have the ability to scroll back, which means we loose some of the backtrace, which isn't ideal. In this commit I propose that we should disable tui mode whenever we handle a fatal signal, or when we hit the internal error code path (e.g. when an assert triggers). With this done then we don't need to update the bt-utils.c code, and the execinfo version of the code (using backtrace_symbols_fd) works just fine. We also get the ability to scroll back to view the error message and all of the backtrace, assuming the users terminal supports scrolling back. The only downside I see with this change is if the tui_disable call itself causes an error for some reason, or, if we handle a single at a time when it is not safe to call tui_disable, in these cases the extra tui_disable call might cause GDB to loose the original error. However, I think (just from personal experience) that the above two issues are pretty rare and the benefits from this change far out weighs the possible drawbacks.
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.