Re: error when compiling dts preprocessed with -g3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hi David,

I am being hit by this problem again. This time on Ubuntu 20.04 LTS with
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04), yocto (hardknott) and
kernel v5.10.

As it's standard kernel built, I am using scripts/Makefile.lib from
kernel sources. This line [1] causes the problem. As you indicated, it
calls the preprocessor and afterwards dtc.

I use the custom hardware (and .dts), however, I think you can reproduce
the problem by calling:

    git clone --depth 1 --single-branch --branch v5.10
    cd linux
    gcc -g3 -O0 -fno-omit-frame-pointer -E -nostdinc
-Iscripts/dtc/include-prefixes -undef -D__DTS__ -x assembler-with-cpp -o
zynqmp-zcu102-revB.dts.tmp arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revB.dts

The last command I extracted and simplified from [1], specific for my
yocto built. With '-g3' option, there are preprocessors directives left
in the produced zynqmp-zcu102-revB.dts.tmp which cause dts to fail.




On 08.06.2021 12:47, Adrian Fiergolski wrote:
> Hi David,
> Thanks for your message.
> I found a workaround for this issue and as I raised the problem almost a
> year ago, I would need time to reproduce it, which unfortunately I can't
> afford these days. Thus I can't support you in debugging this anymore.
> Regards,
> Adrian
> On 08.06.2021 06:18, David Gibson wrote:
>> On Thu, Aug 20, 2020 at 01:32:17PM +0200, Adrian Fiergolski wrote:
>>> Hi David,
>>> Thank you for your reply.
>>> On 20.08.2020 12:27, David Gibson wrote:
>>>> On Fri, Aug 14, 2020 at 08:13:22PM +0200, Adrian Fiergolski wrote:
>>>>> Hi,
>>>>> I am using yocto to build my custom distribution targetting arm64 on
>>>>> Ubuntu 18.04.4.
>>>>> I have an issue compiling dts which was preprocessed with gcc version
>>>>> 7.5.0 (I haven't tried other version) and '-g3' flag. The error message:
>>>> Huh.  It's surprising to me that -g options affect the preprocessor
>>>> behavior at all.
>>>>>     ./scripts/dtc/dtc -O dtb -o
>>>>>     arch/arm64/boot/dts/xilinx/zynqmp-falcon.dtb -b 0
>>>>>     -i/home/afiergol/fastree/falcon/poky/build/tmp/work-shared/falcon-zynqmp/kernel-source/arch/arm64/boot/dts/xilinx/
>>>>>     -i/home/afiergol/fastree/falcon/poky/build/tmp/work-shared/falcon-zynqmp/kernel-source/scripts/dtc/include-prefixes
>>>>>     -Wno-unit_address_vs_reg -Wno-unit_address_format
>>>>>     -Wno-avoid_unnecessary_addr_size -Wno-alias_paths
>>>>>     -Wno-graph_child_address -Wno-simple_bus_reg
>>>>>     -Wno-unique_unit_address -Wno-pci_device_reg  -d
>>>>>     arch/arm64/boot/dts/xilinx/.zynqmp-falcon.dtb.d.dtc.tmp
>>>>>     arch/arm64/boot/dts/xilinx/.zynqmp-falcon.dtb.dts.tmp
>>>>>     Error: <built-in>:1.1-2 syntax error
>>>>>     FATAL ERROR: Unable to parse input tree
>>>>> The part of a preprocessed dts causing issue:
>>>>>     # 1
>>>>>     "/home/afiergol/fastree/falcon/poky/build/tmp/work-shared/falcon-zynqmp/kernel-source/arch/arm64/boot/dts/xilinx/zynqmp-falcon.dts"
>>>>>     # 1
>>>>>     "/home/afiergol/fastree/falcon/poky/build/tmp/work/falcon_zynqmp-poky-linux/linux-xlnx/5.4+gitAUTOINC+22b71b4162-r0/linux-falcon_zynqmp-standard-build//"
>>>>>     # 1 "<built-in>"
>>>>>     #define __STDC__ 1
>>>> If it's preprocessed already, why does it still have #defines?
>>>> This is the cause of the problem - the dtc lexer can hande the lines
>>>> in the preprocessor output with file/linue number information, but it
>>>> doesn't expect there to be remaining preprocessor directives.
>>> Yes, it's preprocessed already by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0.
>>> Are you able to reproduce the issue (any dts including dtsi should give
>>> similar results)?
>> No, I haven't been able to reproduce this problem.  I did hit a
>> different problem in the area, where cpp was generating line number
>> information in a format the dtc lexer didn't expect.  I've just pushed
>> a fix for that.
>> But leaving in #defines in preprocessed code really looks like a
>> problem with how the preprocessor is invoked, not with dtc.  If I'm
>> going to debug this without more messing around than I have time for,
>> please give me *specific* dts/dtsi files to attempt this, and
>> *exactly* how the preprocessor is being invoked.

[Index of Archives]     [Device Tree]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux