public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Liming Gao" <liming.gao@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Schmauss, Erik" <erik.schmauss@intel.com>,
	"felixp@ami.com" <felixp@ami.com>
Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions
Date: Mon, 8 Apr 2019 16:23:11 +0000	[thread overview]
Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4209EE@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <CF6A88132359CE47947DB4C6E1709ED53C597D79@ORSMSX122.amr.corp.intel.com>

[-- 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 --]

  reply	other threads:[~2019-04-08 16:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04 19:08 ASL build tools - EDKII trim tool questions erik.schmauss
2019-04-04 22:10 ` [edk2-devel] " Felix Polyudov
2019-04-04 23:44   ` erik.schmauss
2019-04-08 16:23     ` Liming Gao [this message]
2019-04-08 16:45       ` Schmauss, Erik
  -- strict thread matches above, loose matches on Subject: below --
2019-04-09  1:05 Liming Gao
2019-04-09  9:10 ` Laszlo Ersek
2019-04-11 23:10   ` Schmauss, Erik
2019-04-12 18:03     ` Felix Polyudov
2019-04-12 18:49       ` Schmauss, Erik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A89E2EF3DFEDB4C8BFDE51014F606A14E4209EE@SHSMSX104.ccr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox