public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Michael D Kinney" <michael.d.kinney@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"cheptsov@ispras.ru" <cheptsov@ispras.ru>,
	"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>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] Disabling safe string constraint assertions
Date: Wed, 18 Mar 2020 20:35:12 +0000	[thread overview]
Message-ID: <E92EE9817A31E24EB0585FDF735412F5B9EEB59D@ORSMSX113.amr.corp.intel.com> (raw)
In-Reply-To: <C621C342-5C83-45D1-A501-891A4D1EE34D@ispras.ru>

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

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 <devel@edk2.groups.io> On Behalf Of Vitaly Cheptsov
Sent: Wednesday, March 18, 2020 12:36 PM
To: Laszlo Ersek <lersek@redhat.com>; Andrew Fish <afish@apple.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Marvin Häuser <mhaeuser@outlook.de>; Gao, Liming <liming.gao@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
Cc: 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 #2: Type: text/html, Size: 48117 bytes --]

  reply	other threads:[~2020-03-18 20:35 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               ` Michael D Kinney [this message]
2020-03-18 20:43                 ` [edk2-devel] " Vitaly Cheptsov
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=E92EE9817A31E24EB0585FDF735412F5B9EEB59D@ORSMSX113.amr.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