Oh dear...
Adding linaro-toolchain@lists.linaro.org to see what they have to say (and linaro-uefi, because it's useful information for subscribers of that).
Regards,
Leif
On Tue, Feb 21, 2017 at 08:09:53PM +0000, Evan Lloyd wrote:
To add to Alexei's comments: It seems there is a bug in the newer GCC Pre-processor that messes with the file case. (He is currently checking what file system flags might be affecting that, but older versions work fine).
The questions I'd add are: Is there someone in Linaro who we might discuss the problem with (on the GCC side)? I think there are Linaro guys involved with it, and they may be able to tell us it is confusion on our part. Should we be trying to upstream the fix, or just wait for a new GCC?
Regards, Evan
From: Alexei Fedorov Sent: 21 February 2017 16:37 To: ard.biesheuvel@linaro.org; ryan.harkin@linaro.org; leif.lindholm@linaro.org; Evan Lloyd; Sami Mujawar; Girish Pathak Cc: Mitch Ishihara; Alexei Fedorov Subject: Problem with building AML file from Dsdt.asl for Juno
Hello,
We are facing a problem when compiling Juno's Dsdt.asl file with the following GCC builds:
gcc-linaro-5.3.1-2016.05-i686-mingw32_aarch64-elf
gcc-linaro-6.1.1-2016.08-i686-mingw32_aarch64-elf
gcc-linaro-6.2.1-2016.11-i686-mingw32_aarch64-elf
gcc-linaro-6.3.1-2017.02-i686-mingw32_aarch64-elf
which all show a similar error:
... Trim --source-code -l -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iiii k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iii "C:\ASL\iasl" -pk:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.aml k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iiii Error 6126 - Input file does not appear to be an ASL or data table source file Intel ACPI Component Architecture make: *** [Makefile:325: k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\Dsdt.aml] Error -1
It looks like the problem is with GCC pre-processor running on Dsdt.i file (created after
Trim --asl-file -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.i -i k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\inc.lst k:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\Dsdt.asl
)
See:
"C:\gcc-linaro-6.3.1-2017.02-i686-mingw32_aarch64-elf\bin\aarch64-elf-gcc" -x c -E -include AutoGen.h -Ik:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables -Ik:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\DEBUG -Ik:\ArmPkg -Ik:\ArmPkg\Include -Ik:\ArmPlatformPkg -Ik:\ArmPlatformPkg\Include -Ik:\ArmPlatformPkg\ArmVExpressPkg -Ik:\ArmPlatformPkg\ArmVExpressPkg\Include -Ik:\ArmPlatformPkg\ArmJunoPkg -Ik:\ArmPlatformPkg\ArmJunoPkg\Include -Ik:\EmbeddedPkg -Ik:\EmbeddedPkg\Include -Ik:\MdePkg -Ik:\MdePkg\Include -Ik:\MdePkg\Include\AArch64 -Ik:\MdeModulePkg -Ik:\MdeModulePkg\Include -Ik:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTablesk:\Build\ArmJuno\DEBUG_GCC5AARCH64OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.i > k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iii
For all GCC versions above, the 1st line of Dsdt.iii lists its name & full path in lowercase:
# 1 "k:\build\armjuno\debug_gcc5\aarch64\openplatformpkg\platforms\arm\juno\acpitables\acpitables\output\dsdt.i"
Compare it with Dsdt.iii after pre-processing by GCC from gcc-linaro-4.9.4-2017.01-i686-mingw32_aarch64-elf release:
# 1 "k:\Build\ArmJuno\DEBUG_GCC49\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.i"
For GCC 5.3.1 & above Dsdt.iiii created by
Trim --source-code -l -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iiii k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iii
has 0 length, which causes iASL compiler to fail with:
Error 6126 - Input file does not appear to be an ASL or data table source file
We've got a workaround solution for that problem which involves modification of \BaseTools\Conf\build_rule.template:
In ASL section: [Acpi-Source-Language-File] <InputFile> ?.asl, ?.Asl, ?.ASL
by replacing 3 lines as below:
<Command.GCC, Command.GCCLD># Trim --asl-file -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i -i $(INC_LIST) ${src} # "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii # Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iiii $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} ${src} > $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iiii $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.I
Please share your opinion on that matter.
Alexei.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Tue, Feb 21, 2017 at 12:30 PM, Leif Lindholm leif.lindholm@linaro.org wrote:
We are facing a problem when compiling Juno's Dsdt.asl file with the following GCC builds:
I don't know what AML files are, or what ASL files are, or what the Trim program is, or where your source files are, etc. I can't make sense of any of this other than this bit.
For all GCC versions above, the 1st line of Dsdt.iii lists its name & full path in lowercase: # 1 "k:\build\armjuno\debug_gcc5\aarch64\openplatformpkg\platforms\arm\juno\acpitables\acpitables\output\dsdt.i"
Compare it with Dsdt.iii after pre-processing by GCC from gcc-linaro-4.9.4-2017.01-i686-mingw32_aarch64-elf release: # 1 "k:\Build\ArmJuno\DEBUG_GCC49\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.i"
Windows file systems are case preserving on write and case insensitive on read, so these two lines are equivalent as far as Windows is concerned. Both should work fine for any compiler related purpose. It is a little odd to change the case here though.
I doubt that gcc is messing with file names. I would suspect a newlib change.
I tried reproducing the problem with a simple testcase, but I'm having a lot of trouble getting the linaro mingw32 compiler to work on my Windows machine. The other programs work fine, but the compiler fails with a cryptic error code. Maybe some kind of dll problem?
There are times on windows where you need to convert a file name to lowercase, e.g. comparing two strings to see if they are the same file name. Maybe someplace a file name is converted to lower case for a compare, and then it accidentally uses the lowercase version instead of the original file name? That sounds feasible. Unfortunately, I can't reproduce the problem, as windows isn't cooperating.
Jim
Hi Jim. Thanks for responding - comments inline below:
-----Original Message----- From: Jim Wilson [mailto:jim.wilson@linaro.org] Sent: 21 February 2017 22:22 To: Leif Lindholm Cc: Evan Lloyd; ard.biesheuvel@linaro.org; Mitch Ishihara; Girish Pathak; linaro-toolchain@lists.linaro.org; ryan.harkin@linaro.org; linaro- uefi@lists.linaro.org; Alexei Fedorov; Sami Mujawar Subject: Re: Problem with building AML file from Dsdt.asl for Juno
On Tue, Feb 21, 2017 at 12:30 PM, Leif Lindholm leif.lindholm@linaro.org wrote:
We are facing a problem when compiling Juno's Dsdt.asl file with the
following GCC builds:
I don't know what AML files are, or what ASL files are, or what the Trim program is, or where your source files are, etc. I can't make sense of any of this other than this bit.
That is very reasonable, as ASL, AML and Trim are all features of a sophisticated form of brain damage known as UEFI firmware. The ACPI Source Language (ASL) is pre-processed (using GCC in this case), then run through the Trim script for no good reason I can determine, before compiling. Trim is a script used in the UEFI (well edk2) build, and it pays attention to the pre-processor embedded line info so that it can report errors in the right place. You probably do NOT want to know more about that, if you place any value on your sanity.
For all GCC versions above, the 1st line of Dsdt.iii lists its name & full path
in lowercase:
# 1
"k:\build\armjuno\debug_gcc5\aarch64\openplatformpkg\platforms\ \arm\juno\acpitables\acpitables\output\dsdt.i"
Compare it with Dsdt.iii after pre-processing by GCC from gcc-linaro-
4.9.4-2017.01-i686-mingw32_aarch64-elf release:
# 1
"k:\Build\ArmJuno\DEBUG_GCC49\AARCH64\OpenPlatformPkg\Platf orms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.i"
Windows file systems are case preserving on write and case insensitive on read, so these two lines are equivalent as far as Windows is concerned. Both should work fine for any compiler related purpose. It is a little odd to change the case here though.
You are right on all counts - especially "It is a little odd to change the case here though". :-) We get the problem because the Trim script currently only checks for string equality in the file names. (And fixing that is not trivial, as it has to still work on *nix systems, too.)
I doubt that gcc is messing with file names. I would suspect a newlib change.
So does that imply the GCC behaviour change will not get reverted?
I tried reproducing the problem with a simple testcase, but I'm having a lot of trouble getting the linaro mingw32 compiler to work on my Windows machine. The other programs work fine, but the compiler fails with a cryptic error code. Maybe some kind of dll problem?
There are times on windows where you need to convert a file name to lowercase, e.g. comparing two strings to see if they are the same file name. Maybe someplace a file name is converted to lower case for a compare, and then it accidentally uses the lowercase version instead of the original file name? That sounds feasible. Unfortunately, I can't reproduce the problem, as windows isn't cooperating.
Jim
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Wed, Feb 22, 2017 at 4:51 AM, Evan Lloyd Evan.Lloyd@arm.com wrote:
I doubt that gcc is messing with file names. I would suspect a newlib change.
So does that imply the GCC behaviour change will not get reverted?
I haven't seen a GCC behaviour change yet. I got the mingw32 gcc-linaro-5.3-2016.05 working. When I run gcc -E on a TMP.C file that includes a TMP.H file, I see both TMP.C ahd TMP.H in the -E output as expected. I see the same behaviour from a mingw gcc-linaro-4.9-2016.02. Unfortunately, I can't run any linaro release I've tried from 2016.08 or later and I don't know why. I don't know what you might be doing different that might be generating different results.
I looked at the gcc and newlib sources, but I don't see anything obvious downcasing filenames except for some filename hash table code in libiberty which doesn't appear to be used by either gcc or newlib.
Jim
Jim,
Could you try to build Juno AARCH64 UEFI image from Tianocore EDK II & Linaro OpenPlatformPkg to see if the error persists?
Alexei.
-----Original Message----- From: Jim Wilson [mailto:jim.wilson@linaro.org] Sent: 22 February 2017 17:20 To: Evan Lloyd Evan.Lloyd@arm.com Cc: Leif Lindholm leif.lindholm@linaro.org; ard.biesheuvel@linaro.org; Mitch Ishihara Mitch.Ishihara@arm.com; Girish Pathak Girish.Pathak@arm.com; linaro-toolchain@lists.linaro.org; ryan.harkin@linaro.org; linaro-uefi@lists.linaro.org; Alexei Fedorov Alexei.Fedorov@arm.com; Sami Mujawar Sami.Mujawar@arm.com Subject: Re: Problem with building AML file from Dsdt.asl for Juno
On Wed, Feb 22, 2017 at 4:51 AM, Evan Lloyd Evan.Lloyd@arm.com wrote:
I doubt that gcc is messing with file names. I would suspect a newlib change.
So does that imply the GCC behaviour change will not get reverted?
I haven't seen a GCC behaviour change yet. I got the mingw32 gcc-linaro-5.3-2016.05 working. When I run gcc -E on a TMP.C file that includes a TMP.H file, I see both TMP.C ahd TMP.H in the -E output as expected. I see the same behaviour from a mingw gcc-linaro-4.9-2016.02. Unfortunately, I can't run any linaro release I've tried from 2016.08 or later and I don't know why. I don't know what you might be doing different that might be generating different results.
I looked at the gcc and newlib sources, but I don't see anything obvious downcasing filenames except for some filename hash table code in libiberty which doesn't appear to be used by either gcc or newlib.
Jim IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Wed, Feb 22, 2017 at 10:17 AM, Alexei Fedorov Alexei.Fedorov@arm.com wrote:
Could you try to build Juno AARCH64 UEFI image from Tianocore EDK II & Linaro OpenPlatformPkg to see if the error persists?
Not without detailed instructions. I know what Juno AARCH64 UEFI image means, but I don't know what Tianocore EDK II and Linaro OpenPlatformPkg are.
Jim
Hi,
On 21 February 2017 at 21:30, Leif Lindholm leif.lindholm@linaro.org wrote:
Oh dear...
Adding linaro-toolchain@lists.linaro.org to see what they have to say (and linaro-uefi, because it's useful information for subscribers of that).
Regards,
Leif
On Tue, Feb 21, 2017 at 08:09:53PM +0000, Evan Lloyd wrote:
To add to Alexei's comments: It seems there is a bug in the newer GCC Pre-processor that messes with the file case. (He is currently checking what file system flags might be affecting that, but older versions work fine).
The questions I'd add are: Is there someone in Linaro who we might discuss the problem with (on the GCC side)? I think there are Linaro guys involved with it, and they may be able to tell us it is confusion on our part. Should we be trying to upstream the fix, or just wait for a new GCC?
Regards, Evan
From: Alexei Fedorov Sent: 21 February 2017 16:37 To: ard.biesheuvel@linaro.org; ryan.harkin@linaro.org; leif.lindholm@linaro.org; Evan Lloyd; Sami Mujawar; Girish Pathak Cc: Mitch Ishihara; Alexei Fedorov Subject: Problem with building AML file from Dsdt.asl for Juno
Hello,
We are facing a problem when compiling Juno's Dsdt.asl file with the following GCC builds:
gcc-linaro-5.3.1-2016.05-i686-mingw32_aarch64-elf
gcc-linaro-6.1.1-2016.08-i686-mingw32_aarch64-elf
gcc-linaro-6.2.1-2016.11-i686-mingw32_aarch64-elf
gcc-linaro-6.3.1-2017.02-i686-mingw32_aarch64-elf
which all show a similar error:
... Trim --source-code -l -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iiii k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iii "C:\ASL\iasl" -pk:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.aml k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iiii Error 6126 - Input file does not appear to be an ASL or data table source file Intel ACPI Component Architecture make: *** [Makefile:325: k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\Dsdt.aml] Error -1
Ideally you should open a bug report, with suitable information for us to reproduce the problem.
It looks like the problem is with GCC pre-processor running on Dsdt.i file (created after
Trim --asl-file -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.i -i k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\inc.lst k:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\Dsdt.asl
)
See:
"C:\gcc-linaro-6.3.1-2017.02-i686-mingw32_aarch64-elf\bin\aarch64-elf-gcc" -x c -E -include AutoGen.h -Ik:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables -Ik:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\DEBUG -Ik:\ArmPkg -Ik:\ArmPkg\Include -Ik:\ArmPlatformPkg -Ik:\ArmPlatformPkg\Include -Ik:\ArmPlatformPkg\ArmVExpressPkg -Ik:\ArmPlatformPkg\ArmVExpressPkg\Include -Ik:\ArmPlatformPkg\ArmJunoPkg -Ik:\ArmPlatformPkg\ArmJunoPkg\Include -Ik:\EmbeddedPkg -Ik:\EmbeddedPkg\Include -Ik:\MdePkg -Ik:\MdePkg\Include -Ik:\MdePkg\Include\AArch64 -Ik:\MdeModulePkg -Ik:\MdeModulePkg\Include -Ik:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTablesk:\Build\ArmJuno\DEBUG_GCC5AARCH64OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.i > k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iii
For all GCC versions above, the 1st line of Dsdt.iii lists its name & full path in lowercase:
# 1 "k:\build\armjuno\debug_gcc5\aarch64\openplatformpkg\platforms\arm\juno\acpitables\acpitables\output\dsdt.i"
Compare it with Dsdt.iii after pre-processing by GCC from gcc-linaro-4.9.4-2017.01-i686-mingw32_aarch64-elf release:
# 1 "k:\Build\ArmJuno\DEBUG_GCC49\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.i"
For GCC 5.3.1 & above Dsdt.iiii created by
Trim --source-code -l -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iiii k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iii
has 0 length, which causes iASL compiler to fail with:
Doesn't it at least contain the above lowercase line?
Error 6126 - Input file does not appear to be an ASL or data table source file
Do I understand correctly that gcc-linaro-4.9.4-2017.01 works OK for you, and that switching to any gcc-linaro-5.x or 6.x does not ?
Any chance you/we can reproduce the problem on a Linux host? If the problem is really with translating paths to lowercase, I guess it's a Windows-specific problem, right?
Then, does it really matter? I think Windows FS does not care about case?
We've got a workaround solution for that problem which involves modification of \BaseTools\Conf\build_rule.template:
In ASL section: [Acpi-Source-Language-File] <InputFile> ?.asl, ?.Asl, ?.ASL
by replacing 3 lines as below:
<Command.GCC, Command.GCCLD># Trim --asl-file -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i -i $(INC_LIST) ${src} # "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii # Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iiii $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} ${src} > $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iiii $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.I
Please share your opinion on that matter.
Alexei.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
It seems my previous answer didn't reach the lists, sorry for duplicates. I'm basically asking for more details, how to reproduce, etc...
Christophe
On 22 February 2017 at 10:38, Christophe Lyon christophe.lyon@linaro.org wrote:
Hi,
On 21 February 2017 at 21:30, Leif Lindholm leif.lindholm@linaro.org wrote:
Oh dear...
Adding linaro-toolchain@lists.linaro.org to see what they have to say (and linaro-uefi, because it's useful information for subscribers of that).
Regards,
Leif
On Tue, Feb 21, 2017 at 08:09:53PM +0000, Evan Lloyd wrote:
To add to Alexei's comments: It seems there is a bug in the newer GCC Pre-processor that messes with the file case. (He is currently checking what file system flags might be affecting that, but older versions work fine).
The questions I'd add are: Is there someone in Linaro who we might discuss the problem with (on the GCC side)? I think there are Linaro guys involved with it, and they may be able to tell us it is confusion on our part. Should we be trying to upstream the fix, or just wait for a new GCC?
Regards, Evan
From: Alexei Fedorov Sent: 21 February 2017 16:37 To: ard.biesheuvel@linaro.org; ryan.harkin@linaro.org; leif.lindholm@linaro.org; Evan Lloyd; Sami Mujawar; Girish Pathak Cc: Mitch Ishihara; Alexei Fedorov Subject: Problem with building AML file from Dsdt.asl for Juno
Hello,
We are facing a problem when compiling Juno's Dsdt.asl file with the following GCC builds:
gcc-linaro-5.3.1-2016.05-i686-mingw32_aarch64-elf
gcc-linaro-6.1.1-2016.08-i686-mingw32_aarch64-elf
gcc-linaro-6.2.1-2016.11-i686-mingw32_aarch64-elf
gcc-linaro-6.3.1-2017.02-i686-mingw32_aarch64-elf
which all show a similar error:
... Trim --source-code -l -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iiii k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iii "C:\ASL\iasl" -pk:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.aml k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iiii Error 6126 - Input file does not appear to be an ASL or data table source file Intel ACPI Component Architecture make: *** [Makefile:325: k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\Dsdt.aml] Error -1
Ideally you should open a bug report, with suitable information for us to reproduce the problem.
It looks like the problem is with GCC pre-processor running on Dsdt.i file (created after
Trim --asl-file -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.i -i k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\inc.lst k:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\Dsdt.asl
)
See:
"C:\gcc-linaro-6.3.1-2017.02-i686-mingw32_aarch64-elf\bin\aarch64-elf-gcc" -x c -E -include AutoGen.h -Ik:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables -Ik:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\DEBUG -Ik:\ArmPkg -Ik:\ArmPkg\Include -Ik:\ArmPlatformPkg -Ik:\ArmPlatformPkg\Include -Ik:\ArmPlatformPkg\ArmVExpressPkg -Ik:\ArmPlatformPkg\ArmVExpressPkg\Include -Ik:\ArmPlatformPkg\ArmJunoPkg -Ik:\ArmPlatformPkg\ArmJunoPkg\Include -Ik:\EmbeddedPkg -Ik:\EmbeddedPkg\Include -Ik:\MdePkg -Ik:\MdePkg\Include -Ik:\MdePkg\Include\AArch64 -Ik:\MdeModulePkg -Ik:\MdeModulePkg\Include -Ik:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTablesk:\Build\ArmJuno\DEBUG_GCC5AARCH64OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.i > k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iii
For all GCC versions above, the 1st line of Dsdt.iii lists its name & full path in lowercase:
# 1 "k:\build\armjuno\debug_gcc5\aarch64\openplatformpkg\platforms\arm\juno\acpitables\acpitables\output\dsdt.i"
Compare it with Dsdt.iii after pre-processing by GCC from gcc-linaro-4.9.4-2017.01-i686-mingw32_aarch64-elf release:
# 1 "k:\Build\ArmJuno\DEBUG_GCC49\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.i"
For GCC 5.3.1 & above Dsdt.iiii created by
Trim --source-code -l -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iiii k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT.\Dsdt.iii
has 0 length, which causes iASL compiler to fail with:
Doesn't it at least contain the above lowercase line?
Error 6126 - Input file does not appear to be an ASL or data table source file
Do I understand correctly that gcc-linaro-4.9.4-2017.01 works OK for you, and that switching to any gcc-linaro-5.x or 6.x does not ?
Any chance you/we can reproduce the problem on a Linux host? If the problem is really with translating paths to lowercase, I guess it's a Windows-specific problem, right?
Then, does it really matter? I think Windows FS does not care about case?
We've got a workaround solution for that problem which involves modification of \BaseTools\Conf\build_rule.template:
In ASL section: [Acpi-Source-Language-File] <InputFile> ?.asl, ?.Asl, ?.ASL
by replacing 3 lines as below:
<Command.GCC, Command.GCCLD># Trim --asl-file -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i -i $(INC_LIST) ${src} # "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii # Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iiii $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} ${src} > $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iiii $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.I
Please share your opinion on that matter.
Alexei.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
-
Alexei Fedorov -
Christophe Lyon -
Evan Lloyd -
Jim Wilson -
Leif Lindholm