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

[Pedro Alves <pedro@codesourcery.com>]

On Thursday 06 November 2008 04:25:38, Eli Zaretskii wrote:

> You said (or so I thought) that instead of watching the call to
> ReadFile, one can watch some equivalent call to Int 2Eh which ReadFile
> issues eventually, just like `read' does on Unix:

I said it ends up calling the syscall (as in, it calls some function, that
calls some function, that ..., that ends up calling the syscall), but
I didn't say we can "watch it".  AFAIK, there's no debug event to trap
on it.

> 
> > Eventually the libc 'read' function calls the real 'read' syscall,
> > just like on Windows.
> 
> I'm saying that I don't think such a function of Int 2Eh exists,
> because I think only lower-level sector-oriented disk read commands
> are implemented as software interrupts, and all the higher level
> processing needed for reading the file are not in kernel space.
> 
> > In NT the Win32 API functions are regular functions that are
> > implemented on top of OS services.  The kernel knows nothing about the
> > win32 API.  E.g., the ReadFile function is a wrapper around
> > the user land NtReadFile, which itself is what does the syscall.
> 
> But NtReadFile is also a function, not an Int 2Eh syscall, right?
> 

I thought that was clear from
"user land NtReadFile, which itself is what does the syscall".
I pointed at an url explaining how syscalls are done on NT.

Here's another one, which should be more clear:

 http://www.ddj.com/184410109

And linked from it, you'll find the disassembly of NtCreateFile:

 http://www.ddj.com/showArticle.jhtml?documentID=ddj9701e&pgno=2

The point I am making, is that what you wanted to bind to "catch syscall"
is in fact api-tracing --- tracing normal function calls, which you can do
with breakpoints, and isn't specific to Windows.  I mentioned or implied 
that most users would want to trace Win32 api calls, but those are
not "system calls".  I gave the example of ReadFile.

I mentioned that probably, you could get away with putting breakpoints
on the ntdll functions that themselves do the syscalls, but I didn't
say that's the only way.  There could be other better ways.

Please, let's stop this "I said you said" nonsense.

-- 
Pedro Alves