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