My Wine static analysis tool
Hi I've hacked together a simple tool for analyzing Wine code. Currently it can do the following: 1. Find BOOL functions returning non-BOOL. 2. Find HRESULT functions returning non-HRESULTs. 3. Generate a TRACE() for each function showing all its parameters. It isn't really a formal C parser, as it ignores all preprocessor directives, but this makes it *much* simpler and shorter than a real C parser, and it sees original Windows types like LPCWSTR etc. It's not 100% accurate, but it's very effective. 3 of my recent patches have been generated with its help - and I've barely gotten started. I'd like to add the following features at some stage: * Populate all functions with a TRACE() of their arguments, if they don't already have it. * Scan all GUIDs in include/ and generate a full list of all GUIDs and their names. Then patch debugstr_guid() to also output the name of the GUID when available, and/or search and replace GUIDs in WINEDEBUG traces after they've been recorded. * Update .spec files from .c file contents, and verify .spec file accuracy. * It could be extended to examine contents of functions and enforce the absence of W->A and 32->16 calls, etc. * etc. Anybody interested in using it or helping develop it? Regards Damjan
Damjan Jovanovic <damjan.jov(a)gmail.com> writes:
I'd like to add the following features at some stage: * Populate all functions with a TRACE() of their arguments, if they don't already have it.
Please don't do that. There are many functions that we don't need to trace, or that already have traces in sub-functions, or where it's really the return value that's interesting, etc. -- Alexandre Julliard julliard(a)winehq.org
Am 15.01.2013 18:51, schrieb Damjan Jovanovic:
Hi
I've hacked together a simple tool for analyzing Wine code. Currently it can do the following: 1. Find BOOL functions returning non-BOOL. 2. Find HRESULT functions returning non-HRESULTs. 3. Generate a TRACE() for each function showing all its parameters.
It isn't really a formal C parser, as it ignores all preprocessor directives, but this makes it *much* simpler and shorter than a real C parser, and it sees original Windows types like LPCWSTR etc. It's not 100% accurate, but it's very effective. 3 of my recent patches have been generated with its help - and I've barely gotten started.
I'd like to add the following features at some stage: * Populate all functions with a TRACE() of their arguments, if they don't already have it. * Scan all GUIDs in include/ and generate a full list of all GUIDs and their names. Then patch debugstr_guid() to also output the name of the GUID when available, and/or search and replace GUIDs in WINEDEBUG traces after they've been recorded. * Update .spec files from .c file contents, and verify .spec file accuracy. * It could be extended to examine contents of functions and enforce the absence of W->A and 32->16 calls, etc. * etc.
I'd say put it on github. Which language do you use? I have a hacked tool for one feature, maybe i'll clean it up and send a patch/git-pull-request. -- Best Regards, André Hentschel
On Tue, Jan 15, 2013 at 9:06 PM, André Hentschel <nerv(a)dawncrow.de> wrote:
Am 15.01.2013 18:51, schrieb Damjan Jovanovic:
Hi
I've hacked together a simple tool for analyzing Wine code. Currently it can do the following: 1. Find BOOL functions returning non-BOOL. 2. Find HRESULT functions returning non-HRESULTs. 3. Generate a TRACE() for each function showing all its parameters.
It isn't really a formal C parser, as it ignores all preprocessor directives, but this makes it *much* simpler and shorter than a real C parser, and it sees original Windows types like LPCWSTR etc. It's not 100% accurate, but it's very effective. 3 of my recent patches have been generated with its help - and I've barely gotten started.
I'd like to add the following features at some stage: * Populate all functions with a TRACE() of their arguments, if they don't already have it. * Scan all GUIDs in include/ and generate a full list of all GUIDs and their names. Then patch debugstr_guid() to also output the name of the GUID when available, and/or search and replace GUIDs in WINEDEBUG traces after they've been recorded. * Update .spec files from .c file contents, and verify .spec file accuracy. * It could be extended to examine contents of functions and enforce the absence of W->A and 32->16 calls, etc. * etc.
I'd say put it on github. Which language do you use? I have a hacked tool for one feature, maybe i'll clean it up and send a patch/git-pull-request.
--
Best Regards, André Hentschel
Java svn co https://raisinrefinery.googlecode.com/svn/trunk/RaisinRefinery/GrapeVineScan... mvn package Then run it, eg.: java -jar target/GrapeVineScanner-0.1-SNAPSHOT.jar checkHresultReturns /path/to/wine/dlls/shell32/shlfileop.c Function parse_file_list returns ERROR_INVALID_PARAMETER which might not be a HRESULT Function parse_file_list returns ERROR_ACCESS_DENIED which might not be a HRESULT Function copy_files returns ERROR_SHELL_INTERNAL_FILE_NOT_FOUND which might not be a HRESULT Function copy_files returns ERROR_CANCELLED which might not be a HRESULT Function copy_files returns ERROR_CANCELLED which might not be a HRESULT Function copy_files returns ERROR_CANCELLED which might not be a HRESULT Function copy_files returns ERROR_CANCELLED which might not be a HRESULT Function copy_files returns ERROR_CANCELLED which might not be a HRESULT Function copy_files returns ERROR_CANCELLED which might not be a HRESULT Function copy_files returns ERROR_SUCCESS which might not be a HRESULT Function copy_files returns ERROR_NO_MORE_SEARCH_HANDLES which might not be a HRESULT Function copy_files returns ERROR_SUCCESS which might not be a HRESULT Function copy_files returns ERROR_CANCELLED which might not be a HRESULT Function copy_files returns ERROR_CANCELLED which might not be a HRESULT Function copy_files returns ERROR_SUCCESS which might not be a HRESULT Function delete_files returns ERROR_SUCCESS which might not be a HRESULT Function delete_files returns 0 which isn't a HRESULT constant Function delete_files returns ERROR_PATH_NOT_FOUND which might not be a HRESULT Function delete_files returns ERROR_SUCCESS which might not be a HRESULT Function move_files returns ERROR_CANCELLED which might not be a HRESULT Function move_files returns ERROR_CANCELLED which might not be a HRESULT Function move_files returns ERROR_CANCELLED which might not be a HRESULT Function move_files returns ERROR_CANCELLED which might not be a HRESULT Function move_files returns ERROR_CANCELLED which might not be a HRESULT Function move_files returns ERROR_CANCELLED which might not be a HRESULT Function move_files returns ERROR_SUCCESS which might not be a HRESULT Function rename_files returns ERROR_GEN_FAILURE which might not be a HRESULT Function rename_files returns ERROR_CANCELLED which might not be a HRESULT Function rename_files returns ERROR_SHELL_INTERNAL_FILE_NOT_FOUND which might not be a HRESULT Function rename_files returns ERROR_ALREADY_EXISTS which might not be a HRESULT Function rename_files returns SHNotifyMoveFileW(feFrom->szFullPath, feTo->szFullPath) which might not be a HRESULT Function SHPathPrepareForWriteA returns SHPathPrepareForWriteW(hwnd, modless, wpath, flags) which might not be a HRESULT
On Tue, Jan 15, 2013 at 9:15 PM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote:
On Tue, Jan 15, 2013 at 9:06 PM, André Hentschel <nerv(a)dawncrow.de> wrote:
Am 15.01.2013 18:51, schrieb Damjan Jovanovic:
Hi
I've hacked together a simple tool for analyzing Wine code. Currently it can do the following: 1. Find BOOL functions returning non-BOOL. 2. Find HRESULT functions returning non-HRESULTs. 3. Generate a TRACE() for each function showing all its parameters.
It isn't really a formal C parser, as it ignores all preprocessor directives, but this makes it *much* simpler and shorter than a real C parser, and it sees original Windows types like LPCWSTR etc. It's not 100% accurate, but it's very effective. 3 of my recent patches have been generated with its help - and I've barely gotten started.
I'd like to add the following features at some stage: * Populate all functions with a TRACE() of their arguments, if they don't already have it. * Scan all GUIDs in include/ and generate a full list of all GUIDs and their names. Then patch debugstr_guid() to also output the name of the GUID when available, and/or search and replace GUIDs in WINEDEBUG traces after they've been recorded. * Update .spec files from .c file contents, and verify .spec file accuracy. * It could be extended to examine contents of functions and enforce the absence of W->A and 32->16 calls, etc. * etc.
I'd say put it on github. Which language do you use? I have a hacked tool for one feature, maybe i'll clean it up and send a patch/git-pull-request.
--
Best Regards, André Hentschel
Java svn co https://raisinrefinery.googlecode.com/svn/trunk/RaisinRefinery/GrapeVineScan... mvn package
Or rather: svn co https://raisinrefinery.googlecode.com/svn/trunk/RaisinRefinery cd RaisingRefinery mvn package java -jar GrapeVineScanner/target/GrapeVineScanner-0.1-SNAPSHOT.jar checkHresultReturns /path/to/wine/dlls/shell32/shlfileop.c
participants (3)
-
Alexandre Julliard -
André Hentschel -
Damjan Jovanovic