Re: Fun with LD_PRELOAD

[Doug Evans <xdje42@gmail.com>]

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.