From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Triplett Subject: Re: Ignore the cdecl and stdcall attributes for now. Date: Tue, 22 May 2007 13:32:51 -0700 Message-ID: <46535373.3020109@freedesktop.org> References: <20070515220536.GA23923@redhat.com> <464AA57B.3010205@freedesktop.org> <46520647.9090802@redhat.com> <4652819D.4040101@freedesktop.org> <46530112.2030105@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD0663EE8AE4200CC1411480D" Return-path: Received: from mail2.sea5.speakeasy.net ([69.17.117.4]:60547 "EHLO mail2.sea5.speakeasy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756157AbXEVUdk (ORCPT ); Tue, 22 May 2007 16:33:40 -0400 In-Reply-To: <46530112.2030105@redhat.com> Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Michael Stefaniuc Cc: linux-sparse@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD0663EE8AE4200CC1411480D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael Stefaniuc wrote: > Josh Triplett wrote: >> Michael Stefaniuc wrote: >>> Josh Triplett wrote: >>>> Michael Stefaniuc wrote: >>>> I'd love to see the results you get with Wine; in particular, I'd lo= ve to see >>>> and fix any parse errors. Would you consider posting a build log so= mewhere >>>> with latest Sparse from Git? >>> not sure if you are still interested but here is the output of >>> "building" wine with sparse: >>> http://people.redhat.com/mstefani/wine/download/wine+sparse-make.outp= ut.bz2 >>> It was generated by "make clean; make > make.out 2>&1". Sparse runs >>> before every gcc call in the .c.o: make rule. As the wine build syste= m >>> is verbose you'll see the exact command line used for sparse in the >>> above file. >> Thanks for posting this. (Any particular reason you didn't post it to= >> linux-sparse? If not, feel free to fullquote and CC the list.) > Didn't want to spam the list with it. Couldn't imagine that somebody=20 > wants to wade through 13 MB of Wine+sparse build log. >=20 >> Some observations: > Thanks for your time looking at this. >=20 >> -Wno-transparent-union should help; that would eliminate 318 warnings.= >> >> Don't pass -Wall to sparse unless you really mean it. cgcc filters it= out for >> a reason; just because you have -Wall in CFLAGS for GCC doesn't mean y= ou want >> -Wall for sparse. Sparse -Wall includes some warnings with high false= >> positive rates that you probably don't want. > Ok good to know. I went the easy way just duplicating the gcc command=20 > line and replacing gcc with sparse and adding -D__i386___ as Wine won't= =20 > build without a processor type defined. cgcc will define the processor type too. I highly recommend trying a build with CC=3Dcgcc. You can then pass spar= se flags in CFLAGS, and cgcc will filter them out before calling CC; you can= also specify CHECK=3D"sparse -Wfoo -Wno-bar" if you prefer not to change CFLAGS. > I'm still trying to figure out=20 > if sparse is useful (signal to noise ratio) for Wine. It will likely take some time and Sparse modifications in order to parse Wine; however, I want Sparse to handle as much code as it can, not just Linux. I appreciate you trying it on Wine; I think working on this will help both Wine and Sparse. > Wine has some=20 > constraints (having to follow an existing old grown API; compatibility = > with other C processors on non Linux OSes) that aren't a burden for the= =20 > Linux Kernel. E.g. a patch to move to C99 struct initializer was=20 > recently rejected due to compatibility concerns with other C compilers.= I just committed support for a -Wno-old-initializer flag to turn off the sparse warning on non-C99 initializers. >> In particular, -Wall includes -Wundefined-preprocessor. Avoiding that= would >> probably eliminate thousands of warnings about symbols like _MSC_VER (= at >> least, I would guess so without seeing the source of >> /wine/include/winnt.h:283). With -Wundefined-preprocessor, >> #if expression-containing-SYMBOL >> will generate a warning if you haven't defined >> SYMBOL, and I would guess that happens here. That said, you might wan= t >> something like: >> #if defined(SYMBOL) && SYMBOL > number > I already looked at those and thought to fix them though I'm not sure i= f=20 > it is worth. I would have to look at the C standard what that says. The= =20 > "fix" is trivial and should be compatible with any C compiler. The C standard says that any undefined preprocessor symbol in an #if or #= elif becomes 0. (See http://c0x.coding-guidelines.com/6.10.1.html , item 1859= ). Sparse warns when doing so if you use -Wundefined-preprocessor; you might= or might not want that. I just suggested including defined(SYMBOL) because you might not expect t= he behavior that "#if FOO_VER < number" will pass and include the enclosed c= ode with FOO_VER undefined. >> The undefined preprocessor identifiers from limits.h come from not usi= ng cgcc, >> which defines them. Sparse should ideally define those itself. You c= an work >> around the problem by using cgcc or by defining the symbols on the spa= rse >> command line as cgcc does. > I'll do a run with cgcc tonight instead of sparse and check the differe= nce. Thanks! >> Apart from that, the main culprit looks like the one error you already= >> mentioned and gave the test case for. I don't know the cause of that = one yet. >> As an error, it probably masks any warnings you might otherwise see. > Right. I've tried to run the test case in gdb but i see i need to learn= =20 > the inner workings of sparse before i can make sense of what i see. Feel free to ask if you need help or if you think you might have a theory= =2E - Josh Triplett --------------enigD0663EE8AE4200CC1411480D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGU1N7GJuZRtD+evsRAoFdAJ0VGu7noe1p8xRrpv1bsT/hLKzrLQCeMy/9 hLdAzoX9/fJpPUXQDpiHiYE= =FD+h -----END PGP SIGNATURE----- --------------enigD0663EE8AE4200CC1411480D--