On 29/10/2019 08:23, Luc Van Oostenryck wrote: > 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? No, I was thinking about the opportunity to simplify cgcc! :-D ATB, Ramsay Jones
