Re: [PATCH 1/4] 'catch syscall' feature -- Architecture-independent part

[Eli Zaretskii <eliz@gnu.org>]

> 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''.