jump label v7
in [Kernel]
|
Prev: perf: fix initialization bug in parse_single_tracepoint_event()
Next: core: workque: workqueue recursion when unplugging usb WCDMA modem on 2.6.32 kernel
From: Mike Frysinger on 27 Apr 2010 22:20 On Tue, Apr 27, 2010 at 22:08, Tony Breeds wrote: > In terms of "testing", I build a kernel for each toolchain but I don't boot > them and in the past I think blackfin said that what I had wouldn't actually be > runable. every Blackfin defconfig should be buildable & bootable > Last time I looked the wasn't a non-intel cross-toolchain for blackfin. we provide 32bit and 64bit binaries for people, and a simple script to build up from source. if you're looking for some other arch, you need only ask. it's easy for me to ppc/ppc64/ia64 (and ive done them in the past), but no one has asked for those in a while. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mathieu Desnoyers on 28 Apr 2010 10:20 * Tony Breeds (tony(a)bakeyournoodle.com) wrote: > On Tue, Apr 27, 2010 at 09:49:41PM -0400, Mathieu Desnoyers wrote: > > > The crosstool package from Dan Kegel did a good job for this. Not sure > > it's currently maintained though. It was a very useful project, it's a > > shame if it does not live on. It would be good to have up-to-date and > > tested compilers for various architectures available on kernel.org, > > ideally with access to a package that helps building compilers for > > various architectures. > > Trimmed the CC' as this is a bit of a tangent. > > Crosstool did a good job but seems to be less current than we'd like for the > kernel[1]. Ouch. The build failure ratio is surprisingly high. > When using crosstool in the past I found a lot of the complexity > was in *libc to the toolcahins I've built don';t have a libc so they're only > helpful for kernel (or similar) builds. So maybe we could do something more specialized for kernel needs, e.g. a kcrosstool ? It could be a "simplified" crosstool. Personally, I built a set of cross-compilers with crosstool 0.43 a while ago, but must now do a lot of trial and error to find new correct compiler and toolchain versions for each architecture. It would be good to have a kcrosstool git repository that would: - Have scripts and documentation specialized for Linux kernel build. - Contain an updated list of "working" and "non-working" toolchain versions for each arch. - Could be easily updated; people would just have to report success/failure of their config so these could be added to the git repository. The build could probably prepare a report automatically to lessen the reporter job (I'm even thinking about a scheme that would give the option to report automatically). - Optionally contain documentation on how to set up a cron job to automatically fetch a git tree and do a distributed multi-architecture build each day. I think have this kind of updated tool would be of great value for testing. Thanks, Mathieu > > In terms of "testing", I build a kernel for each toolchain but I don't boot > them and in the past I think blackfin said that what I had wouldn't actually be > runable. Last time I looked the wasn't a non-intel cross-toolchain for blackfin. > > I shoudl also mention that a subset of these compilers are used to build test > linux-next daily. > > Yours Tony > > [1] http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/ -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 28 Apr 2010 18:00 On 04/27/2010 06:49 PM, Mathieu Desnoyers wrote: > * Tony Breeds (tony(a)bakeyournoodle.com) wrote: >> On Tue, Apr 27, 2010 at 05:58:58PM -0700, David Miller wrote: >> >>> The kernel stops compiling after the second patch because >>> kernel/jump_label.c is compiled unconditionally, and this generates an >>> attempt to include asm/alternatives.h which is an x86-only phenomenon. >>> >>> Do you have access to a cross-compile environment or at least some >>> non-x86 system you can test build on before submitting these patch >>> sets? >> >> I heard cross-compilers? >> >> http://kernel.org/pub/tools/crosstool/files/bin/ i686 and x86_64 and 4.4.0 >> compilers suitable for kernel work. >> >> I plan to build 4.4.$latest and 4.5.0 ASAP. >> >> Yours Tony > > The crosstool package from Dan Kegel did a good job for this. Not sure > it's currently maintained though. It was a very useful project, it's a > shame if it does not live on. It would be good to have up-to-date and > tested compilers for various architectures available on kernel.org, > ideally with access to a package that helps building compilers for > various architectures. > Tony is taking over that work. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jason Baron on 30 Apr 2010 13:30
On Tue, Apr 27, 2010 at 05:58:58PM -0700, David Miller wrote: > > > >> David, I re-worked the sparc64 to match the updated interfaces. The > >> code should hopefully compile now, although I did not test the sparc > >> bits. > > > > Thanks for working on this Jason. I'll take a close look at this > > some time today. > > The kernel stops compiling after the second patch because > kernel/jump_label.c is compiled unconditionally, and this generates an > attempt to include asm/alternatives.h which is an x86-only phenomenon. > sorry. jump_label.c no longer requires asm/alternatives.h. It should have been removed in this patch series. > Do you have access to a cross-compile environment or at least some > non-x86 system you can test build on before submitting these patch > sets? > I'll make sure to test the next iteration on non-x86, with at least dummy funtions. thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |