displaced stepping and remote targets

displaced stepping and remote targets

[taylor, david]

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?

Re: displaced stepping and remote targets

[Maciej W. Rozycki]

On Mon, 28 Mar 2016, taylor, david wrote:

> 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.
[...]
> And, other than displaced stepping, the x86_64-pc-linux-gnu configuration
> appears to work just fine.
[...]
> I would expect that for popular processors such as x86, powerpc, arm,
> probably others, reusing an existing configuration would be common.

 You're using a bare-metal target, so it looks to me like you need to 
configure for the `x86_64-elf' target or suchlike; this is what the `elf' 
"OS" is for (with some exceptions).  If there's none currently supported 
for the x86_64 architecture, then you may have to fiddle with the sources 
and/or build scriptery a bit.  Given the similarity of the architectures 
using `i386-elf' as a reference might be a good starting point.

  Maciej

Re: displaced stepping and remote targets

[Yao Qi]

"taylor, david" <david.taylor@emc.com> writes:

> 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)

I am not sure on this...

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

GDB got displaced stepping location from entry-point of symbol before,
but it switched to getting entry point from auxv in case that there is
no symbol, here is the patch
https://sourceware.org/ml/gdb-patches/2015-04/msg00341.html

However, looks you are configuring GDB as linux target, but it doesn't
debug a program on linux target, so it is wrong to fix gdb linux things
(displaced stepping location in your case).

You either have to configure your gdb for bare-metal target, as Maciej
suggested (in this way, displaced stepping isn't supported), or teach
your embedded target and your debugging stub behave like a remote linux
target.

-- 
Yao (齐尧)