From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757784AbcHCLk0 (ORCPT ); Wed, 3 Aug 2016 07:40:26 -0400 Received: from ozlabs.org ([103.22.144.67]:50754 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757842AbcHCLkU (ORCPT ); Wed, 3 Aug 2016 07:40:20 -0400 From: Michael Ellerman To: "Luis R. Rodriguez" , Benjamin Herrenschmidt , Paul Mackerras Cc: linuxppc-dev@lists.ozlabs.org, Fengguang Wu , Guenter Roeck , "linux-kernel\@vger.kernel.org" Subject: Re: linker tables on powerpc - build issues In-Reply-To: References: User-Agent: Notmuch/0.21 (https://notmuchmail.org) Date: Wed, 03 Aug 2016 21:40:17 +1000 Message-ID: <87popqullq.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Luis R. Rodriguez" writes: > I've run into a few compilation issues with linker tables support [0] > [1] on only a few architectures: > > blackfin - compiler issue it seems, I have a work around now in place > arm - some alignment issue - still need to iron this out > powerpc - issue with including on > > The issue with powerpc can be replicated easily with the patch below, > and compilation fails even on a 'make defconfig' configuration, the > issues are recurring include header ordering issues. I've given this > some tries to fix but am still a bit bewildered how to best do this > without affecting non-powerpc compilations. The patch below > replicates the changes in question, it does not include the linker > table work at all, it just includes instead of > to reduce and provide an example of the issues > observed. The list of errors are also pretty endless... so was hoping > some power folks might be able to take a glance if possible. If you > have any ideas, please let me know. What is the end goal? You want to be able to include asm/sections.h in asm/jump_labels.h? So that you can get some macros to wrap the pushsection etc, am I right? The biggest problem I see is dereference_function_descriptor(), which uses probe_kernel(), which pulls in uaccess.h. But it doesn't really make sense for dereference_function_descriptor() to be in sections.h AFAICS. I'll see if I can unstitch it tomorrow. cheers