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

[Pedro Alves <pedro@codesourcery.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.  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 
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.

-- 
Pedro Alves