From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23174 invoked by alias); 6 Nov 2008 14:32:44 -0000 Received: (qmail 23034 invoked by uid 22791); 6 Nov 2008 14:32:39 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 14:31:46 +0000 Received: (qmail 29434 invoked from network); 6 Nov 2008 14:31:44 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Nov 2008 14:31:44 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [PATCH 1/4] 'catch syscall' feature -- =?iso-8859-1?q?=09Architecture-independent=09part?= Date: Thu, 06 Nov 2008 14:32:00 -0000 User-Agent: KMail/1.9.10 Cc: bauerman@br.ibm.com, sergiodj@linux.vnet.ibm.com References: <1225773079.24532.52.camel@miki> <200811052109.29724.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811061426.45512.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00107.txt.bz2 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