mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-11-16 12:34:43 +00:00
e68870e4cd
While testing another patch I'm working on I discovered that passing an empty program name to gdbserver would trigger an assertion, like this: $ gdbserver --multi :54321 "" ../../gdb/gdbserver/../gdb/nat/fork-inferior.c:240: A problem internal to GDBserver has been detected. fork_inferior: Assertion `exec_file != nullptr' failed. User input, no matter how weird, shouldn't be triggering an assertion, so lets fix that. In extended mode, it is valid to start gdbserver without an executable name, like this: $ gdbserver --multi :54321 Here gdbserver doesn't start an inferior, and it is up to GDB to connect, and tell gdbserver what to run, and to then start it running. I did wonder if the empty string case should handled like the no executable name case, but then you get into the situation where the user can specify command line arguments without an inferior, like: $ gdbserver --multi :54321 "" a b c And while there's nothing really wrong with this, and I'm sure someone could come up with a use case for it. I'd like to propose that for now at least, we take the simple approach of not allowing an empty executable name, instead we should give an error, like this: $ gdbserver --multi :54321 "" No program to debug Exiting We can always relax this requirement in the future, and allow the empty executable with or without inferior arguments, if we decide there's a compelling reason for it. It would be simple enough to add this in the future, but once we add support for it, it's much harder to remove the feature in the future, so lets start simple. The non-extended remote case works much the same. It too triggers the assertion currently, and after this patch exits with the same error. Of course, the non-extended remote case never supported not having an inferior, if you did: $ gdbserver :54321 You'd be shown the usage text and gdbserver would exit. Approved-By: Tom Tromey <tom@tromey.com>
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, and so on. 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.