Re: PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?

Andrew Fish

On Feb 17, 2022, at 5:36 PM, Michael D Kinney <michael.d.kinney@...> wrote:

Hi Andrew,
I forgot about the library constraints.
Unless we want to first add a feature to build a library instance for each module type into
a different build output directory, we cannot support setting a FixedAtBuild PCD for each
module type.


Yea I’m thinking this is a good reason to maybe not add more knobs. 

I was trying to get tricky and have code conditionally use a global so I could use the lib XIP when I shot myself in the foot. 


Andrew Fish

If you use PatchableInModule, you can post process all the modules to set individual
module PCD values.  You have to do two steps.  One DSC to build all the modules and
generate AsBuiltInf.  2nd DSC/FDF that references the AsBuildInfs and sets the 
PatchableInModule PCD values in the scope of the modules needed.
The only reason the different ARCHs for PEI and DXE works is because the libs
for each ARCH are build separately and already have different build output locations.
From: Andrew Fish <afish@...> 
Sent: Thursday, February 17, 2022 4:42 PM
To:; Oram, Isaac W <isaac.w.oram@...>
Cc: Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?

On Feb 17, 2022, at 4:26 PM, Oram, Isaac W <isaac.w.oram@...> wrote:

It is a reasonable ask, but I lean towards voting no.  We can more or less do the equivalent by breaking a monolithic build into a set of phase specific build/DSC/FDF or something similar.  That seems more flexible anyway.  Maybe we want binaries with settings based on maturity more than phase.  And so on.

My primary concern that the complexity added to an already complex feature.  PCD have a lot of binary compatibility challenges anyway.  And this doesn't add any that don't already exist, but it does make it a lot easier to introduce a mismatch issue.

I shot my self in the foot with the Fixed* macro in a library so I did not get the drivers override. So I feel that pain. You need to used the non Fixed form from a lib to get the value from the global produced by the driver. 

My more recreational question is if this makes sense in most cases, or if there are a limited set of PCD that it makes sense for.  A lot of similar PCD are much more like shared constants and thus it doesn't make a lot of sense for them to vary across executables.  E.G. drivers are asking for problems if they change max string lengths inconsistently. There are definitely more than one PCD where it seems reasonable.  Maybe they are the "wrong" type though.  Maybe they should be a dynamic type if a flexible usage is desired.

I was trying to have different settings for gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask is regards to the action taken on an ASSERT. 
To be honest it was not my 1st choice and I was working around some early boot exception handling code not saving the EFI_SYSTEM_CONTEXT and blocking the scheme I was trying to use. 

Tangentially related, there was some previous work to make macros for phase architectures.

 PEI_ARCH                            = IA32
 DXE_ARCH                            = X64

Enabling [Components.$(PEI_ARCH)] and [Components.$(DXE_ARCH)]

In my case PEI_ARCH == DXE_ARCH so this kind of trick is not helpful. The reality is this trick only works for non virtualized X64 platforms and the edk2 supports a lot more flavors of platforms than X64. 
Andrew Fish

If we do something with PCD, we should probably try to be consistent with this and maybe extend it or integrate it into DSC syntax.  With standalone MM, it probably makes more sense to have PEI, DXE, and SMM.  RT would also make sense to have different settings.  I have mixed feelings about BDS.  I think it makes sense to see it as a potentially independent phase that isn't currently.  But also probably won't ever be independent from DXE.


-----Original Message-----
From: <> On Behalf Of Andrew Fish via
Sent: Thursday, February 17, 2022 12:22 PM
To: Kinney, Michael D <
Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?

On Feb 17, 2022, at 10:52 AM, Kinney, Michael D <michael.d.kinney@...> wrote:

I agree that your approach is the only way right now.

Do you have a feature request???

Well it does seem like a reasonable thing to be able to do? What do other people think?

I was able to refactor my code and I did not actually end up needing to override every PEIM and the PEI Core.


Andrew Fish


-----Original Message-----
From: Andrew Fish <afish@...>
Sent: Wednesday, February 16, 2022 7:26 PM
To: Kinney, Michael D <michael.d.kinney@...>
Subject: Re: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?

On Feb 16, 2022, at 2:10 PM, Kinney, Michael D <michael.d.kinney@...> wrote:

Hi Andrew,

Current DSC syntax for platform scoped [PcdsXXX] sections only 
supports CPU Arch and SKUID.

So there is no mechanism today to specify different PCD values based 
on module type.

You can manage this in the DSC file, but it does require the module 
scoped <PcdXXX> section for each module INF that requires a 
different value that the platform scoped [PcdXXX] section.


That is what I ended up doing, but it required overriding every PEIM and PEI Core. Seemed kind of excessive.

I think people cheat and use IA32 vs X64 to mean PEI vs. DXE on X64 platforms.


Andrew Fish


-----Original Message-----
From: <> On Behalf Of 
Andrew Fish via
Sent: Wednesday, February 16, 2022 1:02 PM
To: edk2-devel-groups-io <>
Subject: [edk2-devel] PcdDebugPropertyMask in DSC: How to I set different values for PEI and DXE?

I’m trying to have a different platform policy for 
PcdDebugPropertyMask in PEI and DXE. I can’t figure out how to do without overriding every PEIM that I build?

My PEI and DXE has the same arch so I can’t use the CPU Arch to tell them apart.

Is there something I’m missing?


Andrew Fish



Join to automatically receive all group messages.