From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 09 Apr 2019 02:10:41 -0700 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 56A7F307B963; Tue, 9 Apr 2019 09:10:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-114.rdu2.redhat.com [10.10.120.114]) by smtp.corp.redhat.com (Postfix) with ESMTP id C4DBB60BF1; Tue, 9 Apr 2019 09:10:39 +0000 (UTC) Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions To: devel@edk2.groups.io, liming.gao@intel.com, "Schmauss, Erik" , "felixp@ami.com" Cc: "Moore, Robert" References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E420C3A@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <6d5253da-db6a-6492-2f0b-befaac1fe21b@redhat.com> Date: Tue, 9 Apr 2019 11:10:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E420C3A@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Tue, 09 Apr 2019 09:10:41 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/09/19 03:05, Liming Gao wrote: > The full preprocessor means to support C style syntax in ASL code, such = as #include =E2=80=9Cxxx.h=E2=80=9D or #define ASL_MACRO 10. Do you want to= support it? ( ... there's more to it: function-like macros, stringification, token pasting, nested macro invocation, ... ) Thanks Laszlo > Thanks > Liming > From: Schmauss, Erik > Sent: Tuesday, April 9, 2019 12:45 AM > To: Gao, Liming ; devel@edk2.groups.io; felixp@ami= .com > Cc: Moore, Robert > Subject: RE: [edk2-devel] ASL build tools - EDKII trim tool questions >=20 > That wasn=E2=80=99t my exact thought but that could work as well.. >=20 > The idea is to implement full preprocessor support in iASL so that we wo= uldn=E2=80=99t need to use trim and iASL for ASL pre-processing/compilation= and just use iASL. >=20 > Along the way, we might be able to support what you mentioned as well. >=20 > From: Gao, Liming > Sent: Monday, April 8, 2019 9:23 AM > To: devel@edk2.groups.io; Schmauss, Erik >; felixp@ami.com > Subject: RE: [edk2-devel] ASL build tools - EDKII trim tool questions >=20 > Do you mean that iASL compiler will support the preprocessor line style = in the preprocessed ASL file, such as #line 50 "d:\allpkg\edk2\TestPkg\Test= Asl\Test.asi"? If so, iASL compiler can report the accurate error line numb= er in original source file. >=20 > Thanks > Liming > From: devel@edk2.groups.io [mailto:devel@ed= k2.groups.io] On Behalf Of Schmauss, Erik > Sent: Friday, April 5, 2019 7:44 AM > To: devel@edk2.groups.io; felixp@ami.com > Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions >=20 > Hi Felix, >=20 > Thanks for the info! >=20 > I am not a firmware developer by any means. However, it seems difficult = to develop code in an environment where compiler error line numbers do not = match the actual source=E2=80=A6 I=E2=80=99ve heard several people complain= about this and I would like to help alleviate these pain-points if possibl= e (and practical). >=20 > Hypothetically, if iASL had support for a preprocessor that produced the= exact same ASL/AML output as the current toolchain, would there be interes= t in switching build system over to solely use edkii? >=20 > From: devel@edk2.groups.io [mailto:devel@ed= k2.groups.io] On Behalf Of Felix Polyudov > Sent: Thursday, April 4, 2019 3:11 PM > To: devel@edk2.groups.io; Schmauss, Erik > > Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions >=20 > Eric, >=20 > One of the reasons the trim tool is used is to support usage of C macros= in ASL files > (ASL files may include C header files and are processed by a C preproces= sor). > This is edk2 way of reusing the same constant definition across source f= iles in different formats. >=20 > From: devel@edk2.groups.io [mailto:devel@ed= k2.groups.io] On Behalf Of erik.schmauss@intel.com > Sent: Thursday, April 04, 2019 3:08 PM > To: devel@edk2.groups.io > Subject: [edk2-devel] ASL build tools - EDKII trim tool questions >=20 >=20 > Hello, >=20 > I work on the ACPICA project (iASL, acpidump, acpiexec, and etc). I=E2= =80=99ve been looking at the EDKII repository and tools that relate to ACP= I and ASL. >=20 > In particular, I=E2=80=99ve been looking at the trim tool https://github= .com/tianocore/edk2/blob/master/BaseTools/Source/Python/Trim/Trim.py >=20 > According to the source code, the =E2=80=9C--asl-file=E2=80=9D option re= places #include and Include (a.k.a. the =E2=80=9CASL include=E2=80=9D) with= actual contents of the file. >=20 > I would prefer everyone to use iASL compiler to do this instead. The pro= blem with trim is that it makes iASL compiler errors more difficult to unde= rstand because the original file has been preprocessed by trim and the line= numbers from iASL remarks/warnings/errors do not make sense to the program= mer... The iASL compiler handles ASL include statements as well as preproce= ssor #include statements. When compiling these files with include statement= s/directives, iASL displays the correct line number and file name of the in= cluded file. Therefore, I think it would be beneficial to developers to use= only iASL rather than trim "--asl-files" and iASL to work on ASL files. >=20 > I've been talking to some people internally about this trim tool but I w= ould like to ask this community if anyone has thoughts/opinions on deprecat= ing trim's ASL option. >=20 > Thanks, >=20 > Erik >=20 >=20 > P Please consider the environment before printing this email >=20 > The information contained in this message may be confidential and propri= etary to American Megatrends, Inc. This communication is intended to be rea= d only by the individual or entity to whom it is addressed or by their desi= gnee. If the reader of this message is not the intended recipient, you are = on notice that any distribution of this message, in any form, is strictly p= rohibited. Please promptly notify the sender by reply e-mail or by telephon= e at 770-246-8600, and then delete or destroy all copies of the transmissio= n. >=20 >=20 >=20 >=20