On Tue, Oct 29, 2019 at 02:32:15AM +0000, Ramsay Jones wrote: > > > On 28/10/2019 21:43, Luc Van Oostenryck wrote: > > Sparse is universal in the sense that the same executable can > > be used for all architectures. For this, most arch-specific > > setting can be set with an option and the default values > > are taken from the host machine. > > > > This is working nicely for native targets. However, for cross- > > compilation, while seeming to work relatively well (thanks to > > the kernel build system using -m32/-m64 for all archs, for example) > > things can never work 100% correctly. For example, in the case > > an X86-64 host machine is used for an ARM target, the kernel > > build system will call sparse with -m32, Sparse will 'autodetect' > > the target arch as i386 (x86-64 + -m32) and will then predefine > > the macro __i386__. Most of the time this is not a problem (at > > least for the kernel) unless, of course, if the code contains > > something like: > > #ifdef __i386__ > > ... > > #elif __arm__ > > ... > > > > So, add an option --arch=<arch> to specify the target architecture. > > The native arch is still used if no such flag is given. > > How does this interact with the cgcc --target=<spec> and the > (otherwise) guessing of the 'native' specs? I didn't yet looked at how it interacts with cgcc --target=<spec>. I had losely planned to do this after having removed all the defines in cgcc that are now unneeded (integer_type() and define_size_t() are now done by sparse itself, float_types() should also). I think that the OS-specific parts can be kept in cgcc and in the 'arch' parts it would be easy enough to call sparse with the right '--arch=<...>' (either guessed via uname or specified via --target=<spec>, it wouldn't matter). Do you see some complications? --Luc
