From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8859 invoked by alias); 5 Nov 2008 21:10:22 -0000 Received: (qmail 8835 invoked by uid 22791); 5 Nov 2008 21:10:22 -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; Wed, 05 Nov 2008 21:09:33 +0000 Received: (qmail 21276 invoked from network); 5 Nov 2008 21:09:31 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Nov 2008 21:09:31 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [PATCH 1/4] 'catch syscall' feature -- =?utf-8?q?=09Architecture-independent=09part?= Date: Wed, 05 Nov 2008 21:10:00 -0000 User-Agent: KMail/1.9.10 Cc: bauerman@br.ibm.com, sergiodj@linux.vnet.ibm.com References: <1225773079.24532.52.camel@miki> <200811051933.28792.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200811052109.29724.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/msg00093.txt.bz2 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. =C2=A0If you know differently, please tell the detail= s. I don't understand what we're arguing about. I'm not against making it so that a syscall is identified by string instead of number, if it's such a hard design decision that makes it impossible to change things later on. 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. You can write NT programs without touching the win32 api. Heck, cygwin.dll is moving away from it. There are thousands of win32 functions, spread across a big number of dlls that the user could want to break on, in the use case we're talking about. Which of those would you consider candidates to place a breakpoint for "catch syscall"? All of them? Yes, we could probably implement "catch syscall" on Windows by placing a breakpoint on each of these functions: http://www.metasploit.com/users/opcode/syscalls.html ... this to me is the list of functions that makes sense to break at with "catch syscall". In this case, the win32 specific code to implement the feature would probably map the numbers=20 to the function names as well --- the set is bounded. But, as you say, most Windows developers aren't that interested in these. I believe that what you want (and I'd like to have it too), is the ability to easily break on all functions of a given Dll. Something like 'rbreak -public kernel32.dll!' (I believe minimal symbols for dlls we don't have debug info for, are prefixed with the dll name like that, by extracting the function names from the import table, but I'm not sure where that's user visible). Maybe even fold that ability to the 'break' command, and bind all locations to a simple breakpoint with multiple locations. I don't see why this couldn't be implemented on unix as well, for any '.so'. -- but this isn't catching a "system call". I think it would it look strange to do catch syscall "MyDll.dll" to catch all "system functions" in MyDll.dll, for example. --=20 Pedro Alves