Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754056Ab3EaQcQ (ORCPT ); Fri, 31 May 2013 12:32:16 -0400 Received: from mail-ie0-f170.google.com ([209.85.223.170]:55536 "EHLO mail-ie0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754008Ab3EaQcC (ORCPT ); Fri, 31 May 2013 12:32:02 -0400 MIME-Version: 1.0 In-Reply-To: <51A8CA15.4070504@wwwdotorg.org> References: <1369996170.5199.68.camel@zakaz.uk.xensource.com> <20130531114824.60D223E0901@localhost> <51A8CA15.4070504@wwwdotorg.org> From: Grant Likely Date: Fri, 31 May 2013 17:31:39 +0100 X-Google-Sender-Auth: znOJYALP0Vg9B8_kfrX2u8zYa5M Message-ID: Subject: Re: DTB build failure due to preproccessing To: Stephen Warren Cc: Ian Campbell , linux-kernel , "linuxppc-dev@lists.ozlabs.org" , Michal Marek , Stephen Warren , Rob Herring , JonLoeliger , linux-kbuild@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3606 Lines: 80 On Fri, May 31, 2013 at 5:04 PM, Stephen Warren wrote: > On 05/31/2013 05:48 AM, Grant Likely wrote: >> On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell wrote: >>> This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is >>> actually a more general issue: >>> >>> $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb >>> CC scripts/mod/devicetable-offsets.s >>> GEN scripts/mod/devicetable-offsets.h >>> HOSTCC scripts/mod/file2alias.o >>> HOSTLD scripts/mod/modpost >>> DTC arch/powerpc/boot/virtex440-ml510.dtb >>> Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error >>> FATAL ERROR: Unable to parse input tree >>> make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1 >>> make: *** [virtex440-ml510.dtb] Error 2 >>> >>> Line 374 is the "IDSEL 0x16..." line here: >>> interrupt-map = < >>> /* IRQ mapping for pci slots and ALI M1533 >>> ... >>> * management core also isn't used. >>> */ >>> >>> /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */ >>> 0x3000 0 0 1 &xps_intc_0 3 2 >>> 0x3000 0 0 2 &xps_intc_0 2 2 >>> 0x3000 0 0 3 &xps_intc_0 5 2 >>> 0x3000 0 0 4 &xps_intc_0 4 2 >>> >>> Which gets preprocessed into: >>> interrupt-map = < >>> # 375 "arch/powerpc/boot/dts/virtex440-ml510.dts" >>> 0x3000 0 0 1 &xps_intc_0 3 2 >>> 0x3000 0 0 2 &xps_intc_0 2 2 >>> 0x3000 0 0 3 &xps_intc_0 5 2 >>> 0x3000 0 0 4 &xps_intc_0 4 2 >>> >>> If I manually remove the "# 375 " line then that fixes the error >>> (although there is then a subsequent one of the same type). >>> >>> I suppose this is a bug in dtc? It appears to have at least some >>> awareness of these preprocessor line number comments since it manages to >>> report the original source line number. >> >> dtc is only able to track line numbers when the native /include/ >> directive is used. The #include directive doesn't help it. It should be >> added, but until it is the following patch solves the problem: >> >> I've got this patch in my tree. Either Rob or I will push it to Linus in >> the next few days. >> >> g. >> >> --- >> commit d01dccdcb3ea8233b09efb9c24db9f057fbd3b37 >> Author: Grant Likely >> Date: Fri May 31 12:45:18 2013 +0100 >> >> dtc: Suppress cpp linemarker annotations >> >> DTC isn't able to parse cpp linemarker annotations, so suppress them in >> the cpp output by adding the -P flag to the cpp options. > > That's not true; it explicitly does have code to parse the line markers. > I'll have to investigate why it isn't working in this case. > > If you apply this patch, then anyone who has switched to #include rther > than /include/ will get incorrect line numbers in dtc error messages. > Admittedly that's a smaller population right now though. Perhaps we > should just do a kernel-wide conversion though. My mistake. I tested the wrong thing. I've dropped the patch. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/