This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Fun with LD_PRELOAD
- From: Doug Evans <xdje42 at gmail dot com>
- To: Ludovic Courtès <ludo at gnu dot org>
- Cc: guile-user at gnu dot org, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, saugustine at google dot com
- Date: Wed, 5 Feb 2014 10:21:19 -0800
- Subject: Re: Fun with LD_PRELOAD
- Authentication-results: sourceware.org; auth=none
- References: <CAP9bCMRsRrqEYG+7jS-m2EOhByAB+9hTFUuikoNJeJpxGATu5Q at mail dot gmail dot com> <8761ovp1hw dot fsf at gnu dot org>
On Tue, Feb 4, 2014 at 3:21 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi, Doug,
>
> Doug Evans <xdje42@gmail.com> skribis:
>
>> It's kinda useful to see the system call tracing amongst gdb's own
>> debug output, but my real goal is to explore ways of exercising gdb
>> that are otherwise harder to do.
>> With this I can script what happens when gdb does ptrace,waitpid,tkill,etc.
>> Whether this exploration yields anything useful ... TBD.
>
> Looks fun. So the main application would be to stress-test GDB and see
> if it misses signals sent to application threads right when GDB is about
> to stop them, for example, right?
Something like that.
For example, a colleague at Google tripped over a bug that requires a
specific timing to replicate. I don't have all the details at hand,
but I think I'm hitting the same assert.
infrun.c:1948: internal-error: resume: Assertion
`pc_in_thread_step_range (pc, tp)' failed.
AIUI, It happens, for example, when the user does a "next", and a
signal arrives on another thread while the thread being next'd has
stepped into a subroutine (thus requiring gdb to step out to implement
the semantics of "next"). I now have a simple repro (at least for the
assert I'm seeing), and it was very straightforward to write. It
involves tracking the PTRACE_SINGLESTEP being issued to one thread
(that implement "next") and at the right time send a signal to another
thread.
I've made it very easy to add more syscalls, and the wrapping
machinery itself is not gdb specific. Maybe it would be useful in
either apps, I don't know.