gdbserver: prevent assertion caused by passing empty program name

gdbserver: prevent assertion caused by passing empty program name

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>