This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/4] 'catch syscall' feature -- Architecture-independent part
> From: Pedro Alves <pedro@codesourcery.com>
> Date: Wed, 5 Nov 2008 12:28:29 +0000
> Cc: bauerman@br.ibm.com, sergiodj@linux.vnet.ibm.com
>
> > > strace-like tracers on Windows are usually more interested in
> > > tracing calls to all kinds of dlls, and they usually do so by
> > > playing games with the import tables, I believe.
> >
> > I was thinking about the latter, as that is what is usually
> > interesting.
>
> Yes, but that falls into api-tracing land, which is a bit different
> from syscall tracing.
It's different in implementation details, but very similar in essence,
as far as Joe Random Hacker is concerned. From the Windows
programmer's POV, Windows APIs _are_ syscalls.
> When using a debugger, if you're going to be attached to the
> inferior anyway, it doesn't look like it's much interesting to have
> it as a separate feature
Sorry, I don't understand why. If you thought about setting a
breakpoint on a Windows API call, then this is not a trivial matter,
especially if you are not a Windows internals guru.
> If someone would want to implement "catch syscall" for native
> windows, I'd say that some form to catch real syscalls is what
> would make more sense, because that's what you can't do with a
> regular breakpoint.
I find it hard to believe that catching Int 2Eh calls would be
interesting to most Windows programmers. Unlike Linux, the Windows
kernel implements only a tiny portion of useful services, the rest is
mostly user-space DLLs. A radically different architecture calls for
a radically different interpretation of what is a ``syscall''.