| Message ID | d5ab8af1-6a09-9985-7de1-8ad639369795@ramsayjones.plus.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 17/07/17 17:30, Ramsay Jones wrote: > Hi Christopher, > > The 'make selfcheck' target fails very quickly on cygwin, like so: > > $ make selfcheck > CHECK target.c > CHECK parse.c > /usr/include/sys/_default_fcntl.h:163:14: error: redefinition of struct flock > make: *** [Makefile:204: parse.sc] Error 1 > $ > > This is caused by sparse not defining the '__CYGWIN__' macro, which > would have been defined by cgcc, so the follwing fixes that: > > -- >8 -- > diff --git a/Makefile b/Makefile > index 4214e17..a3d3b9c 100644 > --- a/Makefile > +++ b/Makefile > @@ -201,7 +201,7 @@ c2xml.o c2xml.sc: CFLAGS += $(LIBXML_CFLAGS) > $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) $< > > %.sc: %.c sparse > - $(QUIET_CHECK) ./sparse -c $(ALL_CFLAGS) $< > + $(QUIET_CHECK) ./cgcc -c $(ALL_CFLAGS) $< This should have been './cgcc -no-compile', of course. :( ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 17, 2017 at 2:19 PM, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote: > > This should have been './cgcc -no-compile', of course. :( > Yes, of course. I discover that myself too. I am sending out a V2 version of the patches. In the V2 version I move the checker command to be controlled by "$(CHECKER)". For example I can change CHECKER to test-linearize and get the full byte code output. BTW, are you OK I merge your change with mine in the V2 patches? Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 17/07/17 20:16, Christopher Li wrote: > On Mon, Jul 17, 2017 at 2:19 PM, Ramsay Jones > <ramsay@ramsayjones.plus.com> wrote: >> >> This should have been './cgcc -no-compile', of course. :( >> > Yes, of course. I discover that myself too. I am sending out a V2 > version of the patches. > In the V2 version I move the checker command to be controlled by "$(CHECKER)". > For example I can change CHECKER to test-linearize and get the full > byte code output. > > BTW, are you OK I merge your change with mine in the V2 patches? yes, no problem. I nearly have a clean 'make selfcheck' (I suspect you do too!). I was supposed to have gone out a while ago, ... I guess I will not get it finished before I go. :( ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 17, 2017 at 3:28 PM, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote: > > I nearly have a clean 'make selfcheck' (I suspect you do too!). > I was supposed to have gone out a while ago, ... I guess I will > not get it finished before I go. :( I have send out a V2 version of the patch. BTW, I think most of the macro define part of the cgcc should be move to sparse as well. In the end, cgcc can be merge with sparse as one. I think even with all those macro used by user space program, it shouldn't impact the kernel compile, right? Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 18/07/17 13:53, Christopher Li wrote: > On Mon, Jul 17, 2017 at 3:28 PM, Ramsay Jones > <ramsay@ramsayjones.plus.com> wrote: >> >> I nearly have a clean 'make selfcheck' (I suspect you do too!). >> I was supposed to have gone out a while ago, ... I guess I will >> not get it finished before I go. :( > > I have send out a V2 version of the patch. > > BTW, I think most of the macro define part of the cgcc should be move to sparse > as well. In the end, cgcc can be merge with sparse as one. I think > even with all those > macro used by user space program, it shouldn't impact the kernel compile, right? Hmm, I don't think cgcc should be merged into sparse completely no. Some things from cgcc could be moved into sparse, but not everything. One of the main uses of cgcc is as a proxy for (g)cc. (Yes, that could also be moved into sparse, but why bother?) I still have the 'intptr_t' and 'int32_t' warnings on cygwin, which I could solve either in cgcc or sparse (I was leaning in the direction of sparse, because Luc has already added some of these macros). These definitions would not cause any problems on the kernel (well, if they did, it would also be a problem with gcc!). However, I would not like to say whether some of the 'platform user space' macros would cause a problem on the kernel or not. The only way to know is to give it a try! (Unfortunately, due to lack of disk space, I have deleted my kernel git repository). :( ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 18, 2017 at 12:52 PM, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote: > > Hmm, I don't think cgcc should be merged into sparse completely no. > Some things from cgcc could be moved into sparse, but not everything. > One of the main uses of cgcc is as a proxy for (g)cc. (Yes, that could > also be moved into sparse, but why bother?) I think the macro define etc should be merge to sparse. Right now some kernel file compile differently because sparse missing some platform specific macro. The last time I look at it, the coda file system has some header file generating error in sparse. I am thinking maybe have cgcc as symlink to sparse. If sparse detect it is invoke from cgcc, it will do the call gcc part. > I still have the 'intptr_t' and 'int32_t' warnings on cygwin, which I > could solve either in cgcc or sparse (I was leaning in the direction > of sparse, because Luc has already added some of these macros). These > definitions would not cause any problems on the kernel (well, if they > did, it would also be a problem with gcc!). Right, that is my point sparse need to more of those macro to behave more like gcc. > However, I would not like to say whether some of the 'platform user > space' macros would cause a problem on the kernel or not. The only > way to know is to give it a try! (Unfortunately, due to lack of disk > space, I have deleted my kernel git repository). :( It is easy enough to compare for me. I can just turn a kernel check with cgcc and see if there is any difference. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Makefile b/Makefile index 4214e17..a3d3b9c 100644 --- a/Makefile +++ b/Makefile @@ -201,7 +201,7 @@ c2xml.o c2xml.sc: CFLAGS += $(LIBXML_CFLAGS) $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) $< %.sc: %.c sparse - $(QUIET_CHECK) ./sparse -c $(ALL_CFLAGS) $< + $(QUIET_CHECK) ./cgcc -c $(ALL_CFLAGS) $< selfcheck: $(LIB_OBJS:.o=.sc) $(addsuffix .sc, $(PROGRAMS))
Hi Christopher, The 'make selfcheck' target fails very quickly on cygwin, like so: $ make selfcheck CHECK target.c CHECK parse.c /usr/include/sys/_default_fcntl.h:163:14: error: redefinition of struct flock make: *** [Makefile:204: parse.sc] Error 1 $ This is caused by sparse not defining the '__CYGWIN__' macro, which would have been defined by cgcc, so the follwing fixes that: -- >8 -- ---- Having applied the above patch, the output on cygwin is almost the same as Linux. Only two additional warnings (x2 instances), which is caused by sparse not defining some symbols that gcc defines by default. Unfortunately, the C library on cygwin (well the header files anyway) assumes that the compiler will define these symbols (unlike glibc which has reasonable fallbacks). So, I forgot to mention, that on cygwin I have to have the following in my config.mak file to use sparse on the git code base: SPARSE_FLAGS += -D__INTPTR_TYPE__='long int' SPARSE_FLAGS += -D__INT32_TYPE__=int SPARSE_FLAGS += -D__INT32_MAX__=2147483647 SPARSE_FLAGS += -D__UINT32_TYPE__='unsigned int' SPARSE_FLAGS += -D__UINT32_MAX__=4294967295U SPARSE_FLAGS += -D__INT64_TYPE__='long int' SPARSE_FLAGS += -D__INT64_MAX__=9223372036854775807L SPARSE_FLAGS += -D__UINT64_TYPE__='long unsigned int' SPARSE_FLAGS += -D__UINT64_MAX__=18446744073709551615UL SPARSE_FLAGS += -D__INTMAX_TYPE__='long int' SPARSE_FLAGS += -D__INTMAX_MAX__=9223372036854775807L SPARSE_FLAGS += -D__UINTMAX_TYPE__='long unsigned int' SPARSE_FLAGS += -D__UINTMAX_MAX__=18446744073709551615UL SPARSE_FLAGS += -D__SIZE_TYPE__='long unsigned int' SPARSE_FLAGS += -D__SIZE_MAX__=18446744073709551615UL [Just FYI, 'make selfcheck' on cygwin looks like: $ make selfcheck Makefile:67: Your system does not have libxml, disabling c2xml Makefile:80: Your system does not have libgtk2, disabling test-inspect CHECK target.c CHECK parse.c CHECK tokenize.c /usr/include/sys/_intsup.h:68:2: error: "Unable to determine type definition of intptr_t" /usr/include/sys/_intsup.h:75:2: error: "Unable to determine type definition of int32_t" CHECK pre-process.c pre-process.c:712:25: warning: Variable length array is used. pre-process.c:2019:28: warning: Variable length array is used. CHECK symbol.c CHECK lib.c lib.c:194:6: error: symbol 'error_die' redeclared with different type (originally declared at lib.h:98) - different modifiers lib.c:203:6: error: symbol 'die' redeclared with different type (originally declared at lib.h:94) - different modifiers lib.c:283:5: warning: symbol 'arch_msize_long' was not declared. Should it be static? CHECK scope.c CHECK expression.c ... CHECK sparse-llvm.c /usr/include/sys/_intsup.h:68:2: error: "Unable to determine type definition of intptr_t" /usr/include/sys/_intsup.h:75:2: error: "Unable to determine type definition of int32_t" $ Note the additional intptr_t and int32_t errors.] I think Luc already added some of these symbols, but we maybe need to add some more. (This is the difference between applying sparse to a user-space project rather than the kernel). I have to go now, so this is just a heads-up! ;-) ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html