displaced stepping and remote targets

["taylor, david" <david dot taylor at emc dot com>]

When building GDB for an embedded target, oftentimes there
will be an existing target configuration that is 'close enough' to
the desired configuration that rather than create a new config
triplet, you just reuse the existing one.

For example, we have an embedded target with *LOTS* of memory.
The processors are x86-64.  The file format is ELF.  The debug
information is DWARF.  The target is remote and we talk with a
GDB stub via TCP/IP.

And, other than displaced stepping, the x86_64-pc-linux-gnu configuration
appears to work just fine.

While we typically use a GDB that we have built with our changes in it,
it works just fine -- except for displaced stepping -- to use the GNU/Linux
distribution GDB.

Prior to GDB connecting to the stub we set non-stop and async.

We don't have an auxillary vector and don't support qXfer:auxv:read.
If displaced stepping is on, GDB gets an error.  If it is off, it wants to
stop every thread.  We are in the kernel.  Stopping EVERY thread is a
REALLY bad idea.  One thread is servicing the tcp stack.  Stop it and there
goes the communication.  One thread is servicing the GDB requests.
Stop it and we're no longer listening to GDB.  One thread is providing
a heart-beat (amongst other things).  Stop it and the rest of the box
thinks we've gone south...

While adding support for qXfer is on the to-do list, it will be awhile
before it makes it to the top of the list.

Options that come to mind include:

. make the 'how' of displaced stepping user configurable on-the-fly.
    . options might include auxv, entry-point, user provided address,
      target provided address (via qSupported maybe)

. have GNU/Linux displaced stepping fallback to entry-point if auxv
  fails.

I would expect that for popular processors such as x86, powerpc, arm,
probably others, reusing an existing configuration would be common.

Anyone else have good solutions to this problem?