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.