public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Vitaly Cheptsov" <cheptsov@ispras.ru>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Laszlo Ersek" <lersek@redhat.com>,
	"Andrew Fish" <afish@apple.com>,
	"Marvin Häuser" <mhaeuser@outlook.de>,
	"Gao, Liming" <liming.gao@intel.com>,
	"Gao, Zhichao" <zhichao.gao@intel.com>
Subject: Re: [edk2-devel] Disabling safe string constraint assertions
Date: Wed, 18 Mar 2020 23:43:12 +0300	[thread overview]
Message-ID: <D646D0A2-5702-48DC-AD62-508E98E0D5C0@ispras.ru> (raw)
In-Reply-To: <E92EE9817A31E24EB0585FDF735412F5B9EEB59D@ORSMSX113.amr.corp.intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 5156 bytes --]

Mike,

Thanks for the clarification. I failed to find it in the specs, but the code of the BaseTools kind of gave me such a suspect.
Is there any particular reason why this limitation was added? At the moment I do not see a good reason why this is done.

If there is one, I guess we could consider some other approach, for example, we can factor out these functions to a separate DebugHelperLib/DebugBaseLib/DebugCommonLib, which every DebugLib will depend on. This will make sense to me as a workaround of such limitation, as neither us, nor Andrew, as he mentioned previously, are happy of having to duplicate code in DebugLib implementations and update them for a minor Pcd change.

If there is no good reason, to be honest, it feels like we should just fix this. After reading the spec I do not see what kind of compiler issue could arise here with normal PCDs.

Best regards,
Vitaly

> 18 марта 2020 г., в 23:35, Kinney, Michael D <michael.d.kinney@intel.com> написал(а):
> 
> Vitaly,
> 
> The break you are seeing is because you are not using functions to eval the PCD.  This is a known restriction in how PCDs work between libs and modules and is why the current design uses the XxxEnabled() functions.
> 
> I have not reviewed this issue in a very long time, so I do not know if there are any attributes of newer compilers that would allow a different design now.
> 
> Best regards,
> 
> Mike
> 
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>> On Behalf Of Vitaly Cheptsov
> Sent: Wednesday, March 18, 2020 12:36 PM
> To: Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>; Andrew Fish <afish@apple.com <mailto:afish@apple.com>>; Kinney, Michael D <michael.d.kinney@intel.com <mailto:michael.d.kinney@intel.com>>; Marvin Häuser <mhaeuser@outlook.de <mailto:mhaeuser@outlook.de>>; Gao, Liming <liming.gao@intel.com <mailto:liming.gao@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>>
> Cc: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> Subject: Re: [edk2-devel] Disabling safe string constraint assertions
> 
> Hello!
> 
> I have a prototype of the patch, but there currently is an issue with the current EDK II build system.
> I attached the patch to this e-mail, however, it will not compile for reasonably obscure causes.
> 
> From what I understand:
> - DebugLib header now directly uses PCDs from DebugLib, like PcdDebugPropertyMask.
> - Any library implementing DebugLib should now depend on these PCDs, which seems fairly natural (and I fixed that in BaseDebugLibNull).
> - Any library using DebugLib header should depend on DebugLib, which also depend on DebugLib to get its PCDs (that already looks fine).
> 
> However, for some reason DebugLib PCDs are not included in Autogen.h header for other libraries some reason, and we get errors like:
> MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:1151:9: error: use of undeclared identifier '_PCD_GET_MODE_8_PcdDebugPropertyMask'
> 
> I am not familiar with the build system well enough to resolve this, so I either need guidance on where to look first or it will be great if somebody else handles that.
> I do not believe it is a great idea to abandon the idea of dropping DebugAssertEnabled-like functions, so I suggest us to focus on resolving the build system limitation rather than trying a new approach.
> 
> Best regards,
> Vitaly
> 
> 
> 
> 
> 
> 11 марта 2020 г., в 16:14, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>> написал(а):
> 
> On 03/11/20 14:09, Vitaly Cheptsov wrote:
> 
> Hi everyone,
> 
> So, I believe that by now we mostly agreed to let the original
> proposition land as a short-term solution. We end up with:
> 
> 1. A PCD condition within SAFE_STRING_COSTRAINT_CHECK macro.
> 2. Make this condition evaluate to TRUE by default (i.e. ASSERT).
> 3. Update documentation for BaseLib functions to include the information
> about this behaviour.
> 
> The only thing in question is whether this should be a separate PCD or
> an extra bit in PcdDebugPropertyMask. I believe that we almost agreed on
> two things:
> 
> 1. Adding an extra bit to PcdDebugPropertyMask is cleaner.
> 2. Extending DebugLib interface with a new function is not a good idea.
> 
> Therefore I suggest:
> 
> 1.Add #define DEBUG_PROPERTY_ASSERT_CONSTRAINT_ENABLED 0x40.
> 2. Create header-only macros to replace functions like
> DebugAssertEnabled. We can then use these macros in new code and
> deprecate the original functions.
> 3. Enable DEBUG_PROPERTY_ASSERT_CONSTRAINT_ENABLED bit in MdePkg by default.
> 
> I will submit the new version of the patch soon unless there is an
> immediate opposing opinion.
> 
> Not sure about any particular deprecation timeline, but to me the above
> certainly sounds worth submitting for review.
> 
> (NB I don't plan to review in detail -- I just meant to comment on the
> design, since I was asked to.)
> 
> Thanks!
> Laszlo
> 
> 


[-- Attachment #1.2: Type: text/html, Size: 15112 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-03-18 20:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 21:12 Disabling safe string constraint assertions Vitaly Cheptsov
2020-03-03 22:32 ` [edk2-devel] " Andrew Fish
2020-03-04 13:33 ` Laszlo Ersek
2020-03-04 17:53   ` Andrew Fish
2020-03-04 18:18     ` Laszlo Ersek
2020-03-04 18:56       ` Andrew Fish
2020-03-11 13:09         ` cheptsov
2020-03-11 13:14           ` Laszlo Ersek
2020-03-18 19:36             ` Vitaly Cheptsov
2020-03-18 20:35               ` [edk2-devel] " Michael D Kinney
2020-03-18 20:43                 ` Vitaly Cheptsov [this message]
2020-03-18 20:55                   ` Michael D Kinney
2020-03-18 21:31                     ` Vitaly Cheptsov
2020-03-18 21:53                       ` Andrew Fish
2020-03-19  0:04                         ` Vitaly Cheptsov
2020-05-11 12:03                           ` Vitaly Cheptsov
2020-05-11 15:19                             ` Laszlo Ersek
2020-05-11 15:35                               ` Vitaly Cheptsov

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=D646D0A2-5702-48DC-AD62-508E98E0D5C0@ispras.ru \
    --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