Unable to backtrace out of vector page 0xffff0000

[Ulrich Weigand]

The kernel creates a special page visible to user space at 0xffff0000. This page contains (amongst others) small code stubs that can be executed in user space. These include:
- Signal return handler stubs
- ERESTART_RESTARTBLOCK handler stub
- User-mode helpers for atomic operations

Unfortunately, while this page can be accessed from user space code, it is invisible to ptrace and /proc/.../mem accesses, which means GDB cannot retrieve its contents.

This is not ideal in any case, but is particularly harmful if GDB needs to perform code parsing in order to perform proper unwinding (which it generally does, as there is no debug information for code in that page either).

For example, the ERESTART_RESTARTBLOCK handler actually has a stack frame -- it returns to a PC value stored on the user's stack. To unwind after a "sleep" system call was interrupted twice, GDB would have to recognize this situation and understand that stack frame layout -- which it currently cannot do.

We could fix this by hard-coding addresses in the vector page range into GDB, but that isn't really portable as not all of those addresses are guaranteed to remain stable across kernel releases.

It seems at the very least, the kernel would need to allow ptrace access to that page, to allow GDB code scanning to work.

Maybe it would even make sense to convert this page in to a full vDSO like on other platforms, including enough DWARF CFI to self-describe stack frame layouts?

[Ulrich Weigand (uweigand)]

Added linux-linaro since there is kernel impact.

[Loïc Minier (lool)]

Ulrich, Nicolas has a patch but doesn't know how to properly test it; would you mind giving him instructions or simply testing the above kernel patch? If you don't have hardware, Michael or me can rebuild a kernel with the patch

[Ulrich Weigand (uweigand)]

Nicolas, a trivial test of the kernel part would be to just run any application under GDB, stop at main, and try to access the vectors page using something like "x/32x 0xffff0000". This will return an error with current kernels, and should return the correct contents with a patched kernel.

Loic, to actually make the failing GDB test cases success, I'll need to implement GDB changes in addition to the kernel change. I'd appreciate it if you could install the kernel patch on your board; I can then work on those GDB changes there ...

[Nicolas Pitre (npitre)]

OK the previous patch was insufficient.
Here's a new approach.

[Nicolas Pitre (npitre)]

The kernel patch was merged in the linux-linaro-2.6.35 tree
and jcrigby is releasing new kernel packages today with it.

[Ulrich Weigand (uweigand)]

I've now completed an implementation of a GDB unwinder that supports backtracing out of the restart handler on the vector page. Patch is submitted upstream here:
http://sourceware.org/ml/gdb-patches/2011-02/msg00650.html

Note that this confirms kernel support for reading the vector page via ptrace is working fine now (tested with Linaro 2.6.37).

This fixes the following testsuite failures for me:
FAIL: gdb.server/ext-attach.exp: backtrace 2
FAIL: gdb.threads/attachstop-mt.exp: attach3 to stopped bt
FAIL: gdb.threads/attachstop-mt.exp: attach4, exit leaves process sleeping
FAIL: gdb.threads/attach-stopped.exp: threaded: attach2, exit leaves process sleeping
FAIL: gdb.threads/pthreads.exp: check backtrace from main thread
FAIL: gdb.threads/pthreads.exp: apply backtrace command to all three threads

[Ulrich Weigand (uweigand)]

Fix checked in to mainline and Linaro GDB 7.2.