Re: [edk2-devel] ASL build tools - EDKII trim tool questions

Re: [edk2-devel] ASL build tools - EDKII trim tool questions

[Felix Polyudov]

[-- Attachment #1: Type: text/plain, Size: 2427 bytes --]

Eric,

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 preprocessor).
This is edk2 way of reusing the same constant definition across source files in different formats.

From: devel@edk2.groups.io [mailto:devel@edk2.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


Hello,

I work on the ACPICA project (iASL, acpidump, acpiexec, and etc). I’ve been looking at the EDKII repository and tools that relate to ACPI and ASL.

In particular, I’ve been looking at the trim tool https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/Trim/Trim.py

According to the source code, the “--asl-file” option replaces #include and Include (a.k.a. the “ASL include”) with actual contents of the file.

I would prefer everyone to use iASL compiler to do this instead. The problem with trim is that it makes iASL compiler errors more difficult to understand because the original file has been preprocessed by trim and the line numbers from iASL remarks/warnings/errors do not make sense to the programmer... The iASL compiler handles ASL include statements as well as preprocessor #include statements. When compiling these files with include statements/directives, iASL displays the correct line number and file name of the included 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.

I've been talking to some people internally about this trim tool but I would like to ask this community if anyone has thoughts/opinions on deprecating trim's ASL option.

Thanks,

Erik




Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends, Inc.  This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. 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 prohibited.  Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.

[-- Attachment #2: Type: text/html, Size: 25963 bytes --]

Re: [edk2-devel] ASL build tools - EDKII trim tool questions

[erik.schmauss]

[-- Attachment #1: Type: text/plain, Size: 3328 bytes --]

Hi Felix,

Thanks for the info!

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… I’ve heard several people complain about this and I would like to help alleviate these pain-points if possible (and practical).

Hypothetically, if iASL had support for a preprocessor that produced the exact same ASL/AML output as the current toolchain, would there be interest in switching build system over to solely use edkii?

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Felix Polyudov
Sent: Thursday, April 4, 2019 3:11 PM
To: devel@edk2.groups.io; Schmauss, Erik <erik.schmauss@intel.com>
Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions

Eric,

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 preprocessor).
This is edk2 way of reusing the same constant definition across source files in different formats.

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>
Sent: Thursday, April 04, 2019 3:08 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: [edk2-devel] ASL build tools - EDKII trim tool questions


Hello,

I work on the ACPICA project (iASL, acpidump, acpiexec, and etc). I’ve been looking at the EDKII repository and tools that relate to ACPI and ASL.

In particular, I’ve been looking at the trim tool https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/Trim/Trim.py

According to the source code, the “--asl-file” option replaces #include and Include (a.k.a. the “ASL include”) with actual contents of the file.

I would prefer everyone to use iASL compiler to do this instead. The problem with trim is that it makes iASL compiler errors more difficult to understand because the original file has been preprocessed by trim and the line numbers from iASL remarks/warnings/errors do not make sense to the programmer... The iASL compiler handles ASL include statements as well as preprocessor #include statements. When compiling these files with include statements/directives, iASL displays the correct line number and file name of the included 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.

I've been talking to some people internally about this trim tool but I would like to ask this community if anyone has thoughts/opinions on deprecating trim's ASL option.

Thanks,

Erik


P Please consider the environment before printing this email

The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. 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 prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


[-- Attachment #2: Type: text/html, Size: 9539 bytes --]

Re: [edk2-devel] ASL build tools - EDKII trim tool questions

[Liming Gao]

[-- Attachment #1: Type: text/plain, Size: 3925 bytes --]

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\TestAsl\Test.asi"? If so, iASL compiler can report the accurate error line number in original source file.

Thanks
Liming
From: devel@edk2.groups.io [mailto:devel@edk2.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

Hi Felix,

Thanks for the info!

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… I’ve heard several people complain about this and I would like to help alleviate these pain-points if possible (and practical).

Hypothetically, if iASL had support for a preprocessor that produced the exact same ASL/AML output as the current toolchain, would there be interest in switching build system over to solely use edkii?

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Felix Polyudov
Sent: Thursday, April 4, 2019 3:11 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Schmauss, Erik <erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>>
Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions

Eric,

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 preprocessor).
This is edk2 way of reusing the same constant definition across source files in different formats.

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>
Sent: Thursday, April 04, 2019 3:08 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: [edk2-devel] ASL build tools - EDKII trim tool questions


Hello,

I work on the ACPICA project (iASL, acpidump, acpiexec, and etc). I’ve been looking at the EDKII repository and tools that relate to ACPI and ASL.

In particular, I’ve been looking at the trim tool https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/Trim/Trim.py

According to the source code, the “--asl-file” option replaces #include and Include (a.k.a. the “ASL include”) with actual contents of the file.

I would prefer everyone to use iASL compiler to do this instead. The problem with trim is that it makes iASL compiler errors more difficult to understand because the original file has been preprocessed by trim and the line numbers from iASL remarks/warnings/errors do not make sense to the programmer... The iASL compiler handles ASL include statements as well as preprocessor #include statements. When compiling these files with include statements/directives, iASL displays the correct line number and file name of the included 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.

I've been talking to some people internally about this trim tool but I would like to ask this community if anyone has thoughts/opinions on deprecating trim's ASL option.

Thanks,

Erik


P Please consider the environment before printing this email

The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. 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 prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


[-- Attachment #2: Type: text/html, Size: 12104 bytes --]

Re: [edk2-devel] ASL build tools - EDKII trim tool questions

[Schmauss, Erik]

[-- Attachment #1: Type: text/plain, Size: 4521 bytes --]

That wasn’t my exact thought but that could work as well..

The idea is to implement full preprocessor support in iASL so that we wouldn’t need to use trim and iASL for ASL pre-processing/compilation and just use iASL.

Along the way, we might be able to support what you mentioned as well.

From: Gao, Liming
Sent: Monday, April 8, 2019 9:23 AM
To: devel@edk2.groups.io; Schmauss, Erik <erik.schmauss@intel.com>; felixp@ami.com
Subject: RE: [edk2-devel] ASL build tools - EDKII trim tool questions

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\TestAsl\Test.asi"? If so, iASL compiler can report the accurate error line number in original source file.

Thanks
Liming
From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Schmauss, Erik
Sent: Friday, April 5, 2019 7:44 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; felixp@ami.com<mailto:felixp@ami.com>
Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions

Hi Felix,

Thanks for the info!

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… I’ve heard several people complain about this and I would like to help alleviate these pain-points if possible (and practical).

Hypothetically, if iASL had support for a preprocessor that produced the exact same ASL/AML output as the current toolchain, would there be interest in switching build system over to solely use edkii?

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Felix Polyudov
Sent: Thursday, April 4, 2019 3:11 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Schmauss, Erik <erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>>
Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions

Eric,

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 preprocessor).
This is edk2 way of reusing the same constant definition across source files in different formats.

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>
Sent: Thursday, April 04, 2019 3:08 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: [edk2-devel] ASL build tools - EDKII trim tool questions


Hello,

I work on the ACPICA project (iASL, acpidump, acpiexec, and etc). I’ve been looking at the EDKII repository and tools that relate to ACPI and ASL.

In particular, I’ve been looking at the trim tool https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/Trim/Trim.py

According to the source code, the “--asl-file” option replaces #include and Include (a.k.a. the “ASL include”) with actual contents of the file.

I would prefer everyone to use iASL compiler to do this instead. The problem with trim is that it makes iASL compiler errors more difficult to understand because the original file has been preprocessed by trim and the line numbers from iASL remarks/warnings/errors do not make sense to the programmer... The iASL compiler handles ASL include statements as well as preprocessor #include statements. When compiling these files with include statements/directives, iASL displays the correct line number and file name of the included 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.

I've been talking to some people internally about this trim tool but I would like to ask this community if anyone has thoughts/opinions on deprecating trim's ASL option.

Thanks,

Erik


P Please consider the environment before printing this email

The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. 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 prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


[-- Attachment #2: Type: text/html, Size: 14825 bytes --]

Re: [edk2-devel] ASL build tools - EDKII trim tool questions

[Liming Gao]

[-- Attachment #1: Type: text/plain, Size: 5028 bytes --]

The full preprocessor means to support C style syntax in ASL code, such as #include “xxx.h” or #define ASL_MACRO 10. Do you want to support it?

Thanks
Liming
From: Schmauss, Erik
Sent: Tuesday, April 9, 2019 12:45 AM
To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; felixp@ami.com
Cc: Moore, Robert <robert.moore@intel.com>
Subject: RE: [edk2-devel] ASL build tools - EDKII trim tool questions

That wasn’t my exact thought but that could work as well..

The idea is to implement full preprocessor support in iASL so that we wouldn’t need to use trim and iASL for ASL pre-processing/compilation and just use iASL.

Along the way, we might be able to support what you mentioned as well.

From: Gao, Liming
Sent: Monday, April 8, 2019 9:23 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Schmauss, Erik <erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>>; felixp@ami.com<mailto:felixp@ami.com>
Subject: RE: [edk2-devel] ASL build tools - EDKII trim tool questions

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\TestAsl\Test.asi"? If so, iASL compiler can report the accurate error line number in original source file.

Thanks
Liming
From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Schmauss, Erik
Sent: Friday, April 5, 2019 7:44 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; felixp@ami.com<mailto:felixp@ami.com>
Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions

Hi Felix,

Thanks for the info!

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… I’ve heard several people complain about this and I would like to help alleviate these pain-points if possible (and practical).

Hypothetically, if iASL had support for a preprocessor that produced the exact same ASL/AML output as the current toolchain, would there be interest in switching build system over to solely use edkii?

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Felix Polyudov
Sent: Thursday, April 4, 2019 3:11 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Schmauss, Erik <erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>>
Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions

Eric,

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 preprocessor).
This is edk2 way of reusing the same constant definition across source files in different formats.

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>
Sent: Thursday, April 04, 2019 3:08 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: [edk2-devel] ASL build tools - EDKII trim tool questions


Hello,

I work on the ACPICA project (iASL, acpidump, acpiexec, and etc). I’ve been looking at the EDKII repository and tools that relate to ACPI and ASL.

In particular, I’ve been looking at the trim tool https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/Trim/Trim.py

According to the source code, the “--asl-file” option replaces #include and Include (a.k.a. the “ASL include”) with actual contents of the file.

I would prefer everyone to use iASL compiler to do this instead. The problem with trim is that it makes iASL compiler errors more difficult to understand because the original file has been preprocessed by trim and the line numbers from iASL remarks/warnings/errors do not make sense to the programmer... The iASL compiler handles ASL include statements as well as preprocessor #include statements. When compiling these files with include statements/directives, iASL displays the correct line number and file name of the included 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.

I've been talking to some people internally about this trim tool but I would like to ask this community if anyone has thoughts/opinions on deprecating trim's ASL option.

Thanks,

Erik


P Please consider the environment before printing this email

The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. 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 prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


[-- Attachment #2: Type: text/html, Size: 16090 bytes --]

Re: [edk2-devel] ASL build tools - EDKII trim tool questions

[Laszlo Ersek]

On 04/09/19 03:05, Liming Gao wrote:
> The full preprocessor means to support C style syntax in ASL code, such as #include “xxx.h” 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 <liming.gao@intel.com>; devel@edk2.groups.io; felixp@ami.com
> Cc: Moore, Robert <robert.moore@intel.com>
> Subject: RE: [edk2-devel] ASL build tools - EDKII trim tool questions
> 
> That wasn’t my exact thought but that could work as well..
> 
> The idea is to implement full preprocessor support in iASL so that we wouldn’t need to use trim and iASL for ASL pre-processing/compilation and just use iASL.
> 
> Along the way, we might be able to support what you mentioned as well.
> 
> From: Gao, Liming
> Sent: Monday, April 8, 2019 9:23 AM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Schmauss, Erik <erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>>; felixp@ami.com<mailto:felixp@ami.com>
> Subject: RE: [edk2-devel] ASL build tools - EDKII trim tool questions
> 
> 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\TestAsl\Test.asi"? If so, iASL compiler can report the accurate error line number in original source file.
> 
> Thanks
> Liming
> From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Schmauss, Erik
> Sent: Friday, April 5, 2019 7:44 AM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; felixp@ami.com<mailto:felixp@ami.com>
> Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions
> 
> Hi Felix,
> 
> Thanks for the info!
> 
> 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… I’ve heard several people complain about this and I would like to help alleviate these pain-points if possible (and practical).
> 
> Hypothetically, if iASL had support for a preprocessor that produced the exact same ASL/AML output as the current toolchain, would there be interest in switching build system over to solely use edkii?
> 
> From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Felix Polyudov
> Sent: Thursday, April 4, 2019 3:11 PM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Schmauss, Erik <erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>>
> Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions
> 
> Eric,
> 
> 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 preprocessor).
> This is edk2 way of reusing the same constant definition across source files in different formats.
> 
> From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>
> Sent: Thursday, April 04, 2019 3:08 PM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> Subject: [edk2-devel] ASL build tools - EDKII trim tool questions
> 
> 
> Hello,
> 
> I work on the ACPICA project (iASL, acpidump, acpiexec, and etc). I’ve been looking at the EDKII repository and tools that relate to ACPI and ASL.
> 
> In particular, I’ve been looking at the trim tool https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/Trim/Trim.py
> 
> According to the source code, the “--asl-file” option replaces #include and Include (a.k.a. the “ASL include”) with actual contents of the file.
> 
> I would prefer everyone to use iASL compiler to do this instead. The problem with trim is that it makes iASL compiler errors more difficult to understand because the original file has been preprocessed by trim and the line numbers from iASL remarks/warnings/errors do not make sense to the programmer... The iASL compiler handles ASL include statements as well as preprocessor #include statements. When compiling these files with include statements/directives, iASL displays the correct line number and file name of the included 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.
> 
> I've been talking to some people internally about this trim tool but I would like to ask this community if anyone has thoughts/opinions on deprecating trim's ASL option.
> 
> Thanks,
> 
> Erik
> 
> 
> P Please consider the environment before printing this email
> 
> The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. 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 prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.
> 
> 
> 
> 

Re: [edk2-devel] ASL build tools - EDKII trim tool questions

[Schmauss, Erik]

> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> Behalf Of Laszlo Ersek
> Sent: Tuesday, April 9, 2019 2:11 AM
> To: devel@edk2.groups.io; Gao, Liming <liming.gao@intel.com>;
> Schmauss, Erik <erik.schmauss@intel.com>; felixp@ami.com
> Cc: Moore, Robert <robert.moore@intel.com>
> Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions
> 
> On 04/09/19 03:05, Liming Gao wrote:
> > The full preprocessor means to support C style syntax in ASL code,
> such as #include “xxx.h” 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, ...

Yes, the current iASL preprocessor implementation is incomplete
but we might be able to either develop our own or import an existing
preprocessor if it has the correct license.

> 
> )
> 
> Thanks
> Laszlo
> 
> > Thanks
> > Liming
> > From: Schmauss, Erik
> > Sent: Tuesday, April 9, 2019 12:45 AM
> > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io;
> > felixp@ami.com
> > Cc: Moore, Robert <robert.moore@intel.com>
> > Subject: RE: [edk2-devel] ASL build tools - EDKII trim tool questions
> >
> > That wasn’t my exact thought but that could work as well..
> >
> > The idea is to implement full preprocessor support in iASL so that we
> wouldn’t need to use trim and iASL for ASL pre-processing/compilation
> and just use iASL.
> >
> > Along the way, we might be able to support what you mentioned as
> well.
> >
> > From: Gao, Liming
> > Sent: Monday, April 8, 2019 9:23 AM
> > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> Schmauss, Erik
> > <erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>>;
> > felixp@ami.com<mailto:felixp@ami.com>
> > Subject: RE: [edk2-devel] ASL build tools - EDKII trim tool questions
> >
> > 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\TestAsl\Test.asi"? If so, iASL compiler can
> report the accurate error line number in original source file.
> >
> > Thanks
> > Liming
> > From: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > [mailto:devel@edk2.groups.io] On Behalf Of Schmauss, Erik
> > Sent: Friday, April 5, 2019 7:44 AM
> > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> > felixp@ami.com<mailto:felixp@ami.com>
> > Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions
> >
> > Hi Felix,
> >
> > Thanks for the info!
> >
> > 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… I’ve heard several people
> complain about this and I would like to help alleviate these pain-points
> if possible (and practical).
> >
> > Hypothetically, if iASL had support for a preprocessor that produced
> the exact same ASL/AML output as the current toolchain, would there
> be interest in switching build system over to solely use edkii?
> >
> > From: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > [mailto:devel@edk2.groups.io] On Behalf Of Felix Polyudov
> > Sent: Thursday, April 4, 2019 3:11 PM
> > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>;
> Schmauss, Erik
> > <erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>>
> > Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions
> >
> > Eric,
> >
> > 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 preprocessor).
> > This is edk2 way of reusing the same constant definition across
> source files in different formats.
> >
> > From: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > [mailto:devel@edk2.groups.io] On Behalf Of
> > erik.schmauss@intel.com<mailto:erik.schmauss@intel.com>
> > Sent: Thursday, April 04, 2019 3:08 PM
> > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> > Subject: [edk2-devel] ASL build tools - EDKII trim tool questions
> >
> >
> > Hello,
> >
> > I work on the ACPICA project (iASL, acpidump, acpiexec, and etc).
> I’ve been looking at the EDKII repository and tools that relate to ACPI
> and ASL.
> >
> > In particular, I’ve been looking at the trim tool
> >
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/P
> ython/
> > Trim/Trim.py
> >
> > According to the source code, the “--asl-file” option replaces
> #include and Include (a.k.a. the “ASL include”) with actual contents of
> the file.
> >
> > I would prefer everyone to use iASL compiler to do this instead. The
> problem with trim is that it makes iASL compiler errors more difficult to
> understand because the original file has been preprocessed by trim
> and the line numbers from iASL remarks/warnings/errors do not make
> sense to the programmer... The iASL compiler handles ASL include
> statements as well as preprocessor #include statements. When
> compiling these files with include statements/directives, iASL displays
> the correct line number and file name of the included 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.
> >
> > I've been talking to some people internally about this trim tool but I
> would like to ask this community if anyone has thoughts/opinions on
> deprecating trim's ASL option.
> >
> > Thanks,
> >
> > Erik
> >
> >
> > P Please consider the environment before printing this email
> >
> > The information contained in this message may be confidential and
> proprietary to American Megatrends, Inc. This communication is
> intended to be read only by the individual or entity to whom it is
> addressed or by their designee. 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 prohibited. Please promptly notify the
> sender by reply e-mail or by telephone at 770-246-8600, and then
> delete or destroy all copies of the transmission.
> >
> >
> >
> >
> 
> 
> 

Re: [edk2-devel] ASL build tools - EDKII trim tool questions

[Felix Polyudov]

> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Schmauss, Erik
> Sent: Thursday, April 11, 2019 7:10 PM
> Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions


> Yes, the current iASL preprocessor implementation is incomplete
> but we might be able to either develop our own or import an existing
> preprocessor if it has the correct license.

Eric,

It depends on the end goal.
If the goal is to display correct line numbers in the error messages, just adding support for #line directive is enough.
If the goal is to compile ASL file with a single iasl run without usage of other tools such as Trim, I don't think even having a full-fledged preprocessed would suffice.
In edk2, header files included into ASL files may contain C constructs, such as typedef's, alien to ASL compiler.
The Trim tool cleans them up prior to running IASL.
So even if iasl will be able to perform full preprocessing , Trim would still be required unless edk2 conventions are changed to require ASL-friendly include headers.

Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends, Inc.  This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. 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 prohibited.  Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.

Re: [edk2-devel] ASL build tools - EDKII trim tool questions

[Schmauss, Erik]

> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> Behalf Of Felix Polyudov
> Sent: Friday, April 12, 2019 11:04 AM
> To: devel@edk2.groups.io; Schmauss, Erik
> <erik.schmauss@intel.com>; lersek@redhat.com; Gao, Liming
> <liming.gao@intel.com>
> Cc: Moore, Robert <robert.moore@intel.com>
> Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> Behalf Of
> > Schmauss, Erik
> > Sent: Thursday, April 11, 2019 7:10 PM
> > Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions
> 
> 
> > Yes, the current iASL preprocessor implementation is incomplete but
> we
> > might be able to either develop our own or import an existing
> > preprocessor if it has the correct license.
> 
> Eric,
> 
> It depends on the end goal.
> If the goal is to display correct line numbers in the error messages, just
> adding support for #line directive is enough.
> If the goal is to compile ASL file with a single iasl run without usage of
> other tools such as Trim, I don't think even having a full-fledged
> preprocessed would suffice.
> In edk2, header files included into ASL files may contain C constructs,
> such as typedef's, alien to ASL compiler.

Ok yeah, this sounds a little complicated. I'll discuss this with Bob (Robert Moore) and a few others.
My current thought is that we can start with the simple step of adding line number support and go from there.

Thanks for the discussion everyone!

Erik

> The Trim tool cleans them up prior to running IASL.
> So even if iasl will be able to perform full preprocessing , Trim would
> still be required unless edk2 conventions are changed to require ASL-
> friendly include headers.
> 
> Please consider the environment before printing this email.
> 
> The information contained in this message may be confidential and
> proprietary to American Megatrends, Inc.  This communication is
> intended to be read only by the individual or entity to whom it is
> addressed or by their designee. 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 prohibited.  Please promptly notify the
> sender by reply e-mail or by telephone at 770-246-8600, and then
> delete or destroy all copies of the transmission.
> \x06    *
>  y,b  yǢ 楖g   \x1e ǧ  - +    V'  \x17  #  )   { ^[m   y 6  . Ȩ \x0f z   g   \x1e \x7f= C.     '!  l  +  l
> M5  ｽ     N w u ޗ 0   vM     *\x14 ˛   m m  ?  d
> 躛"  ?u ޗ    ޮ),r\x19   " ץr