This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> From: Pedro Alves <pedro@codesourcery.com>
> Date: Wed, 5 Nov 2008 21:09:29 +0000
> Cc: bauerman@br.ibm.com,
>  sergiodj@linux.vnet.ibm.com
> 
> On Wednesday 05 November 2008 20:34:24, Eli Zaretskii wrote:
> > I don't think `ReadFile', the Windows equivalent of `read', calls Int
> > 2Eh to read a file. ?If you know differently, please tell the details.
> 
> I don't understand what we're arguing about.

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:

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]