Tim,
What do you mean by "adds a package to the build"? The only way to add content
to a FW build is to list the additional module INF files in the DSC/FDF file.
If the module INF files are listed, then the PCD Database will include the PCDs
listed.
This may be a mismatch in the use of the PCD feature. The PCD Database is
intended to be constructed at build time based on the FW components known at
build time. It sounds like you are trying to do something more dynamic which
is what the PPI and Protocol databases are typically used for.
Thanks,
Mike
From: Tim Lewis [mailto:[email protected]]
Sent: Friday, August 09, 2013 10:10 AM
To: [email protected]
Subject: Re: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs
Disappear
Mike -
Not a non-FW component, just another module. Consider I have a case (real life)
where I want to add PCDs from a variety of packages all with different token
numbers, but the same GUID. A driver then accesses the PCD database to find all
PCD tokens with a specified GUID (using GetNextTokeN()), not knowing exactly
which packages were included in the build. Right now, when someone adds the
package to the build (and thus, its .dec) they must also include a dummy .inf
file that references the PCD. And thus we have
yet-another-way-that-a-feature-is-added-to-EDK2.
I understand the desire to minimize flash space. But (a) this behavior is not
documented and (b) it can't be turned off either globally or selectively. We
turn one and off other flash-consuming features with feature flag PCDs, or by
removing them from the DSC/FDF. But for this one I must update a .dec and a
dummy .inf.
Some of this boils down to the lack of conditionals in INFs and the fact that
the EDK2 build system relies so heavily on INFs to generate/pull in other
features. If you accidentally put an extra GUID in your file, it is no big
deal, because optimization will remove it in most cases because it is
unreferenced using declspec(selectany) or its analog. But PCDs are global
resources, like strings or bitmaps. In fact, strings have similar issues (try
to put a string the .uni file and then access it without using the string token)
Tim
From: Kinney, Michael D [mailto:[email protected]]
Sent: Friday, August 09, 2013 9:56 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs
Disappear
Tim,
Even if a PCD is only accessed at runtime, it must be access by a runtime FW
module, which means it must be listed in the INF for the runtime FW module.
What is use case in which a PCD is only accessed by a non FW component and how
would such a component access the PCD?
The PCD database takes up space in the FLASH, so the default behavior of the
build tools is to only include the PCDs that are actually accessed by the set
of modules that are included in the build.
Best regards,
Mike
From: Tim Lewis [mailto:[email protected]]
Sent: Friday, August 09, 2013 8:59 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs
Disappear
Liming -
The root question is: what criteria is used to include PCDs in the PCD
database? Currently there is no way to include PCDs in the database unless each
one is listed in an INF. And there is no documentation to this effect.
In my opinion, any Dynamic, since it is possible that the PCD will be accessed
at runtime without using any PCD macros.
Tim
From: Gao, Liming [mailto:[email protected]]
Sent: Thursday, August 08, 2013 10:49 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs
Disappear
Tim:
This is like a feature request on generating PCD DataBase to include
DynamicExPcd. This may need more discussion to figure out the way on which PCD
will be included. Any DynamicEx PCD defined in Package DEC file? Or those
DynamicEx PCD used in Platform DSC file?
Thanks
Liming
From: Tim Lewis [mailto:[email protected]]
Sent: Tuesday, August 06, 2013 1:45 AM
To: [email protected]<mailto:[email protected]>
Subject: [edk2] PCD Database Issue #3: Build-Time Pruning Makes PCDs Disappear
An undocumented feature of the EDK2 build system prunes PCD entries from the
PCD database if no INF refers to them. This causes problems when PCD accesses
happen purely at runtime using generated PCD token numbers (i.e. the token
number is some form of 0x2000+X) or when PCD tokens are meant to be discovered
by searching through certain GUID (i.e. using GetNextToken() with a specific
GUID returns all PCDs associated with it). Currently, in order to work around
this, every time we create this type of PCD in the project's .dec fie, we must
also add it to an .inf.
I understand the value of auto-pruning. Currently INFs do not have a way to
disable references to PCDs that are not used because of feature flags. But
there needs to be some way to turn off this undocumented behavior.
Tim
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
