On 22.06.2024 01:27, Stefano Stabellini wrote: > On Fri, 21 Jun 2024, Jan Beulich wrote: >> On 21.06.2024 03:02, Stefano Stabellini wrote: >>> On Thu, 20 Jun 2024, Jan Beulich wrote: >>>> On 19.06.2024 19:09, Alessandro Zucchelli wrote: >>>>> Rule 21.2 reports identifiers reserved for the C and POSIX standard >>>>> libraries: all xen's translation units are compiled with option >>>>> -nostdinc, this guarantees that these libraries are not used, therefore >>>>> a justification is provided for allowing uses of such identifiers in >>>>> the project. >>>>> Builtins starting with "__builtin_" still remain available. >>>>> >>>>> No functional change. >>>>> >>>>> Signed-off-by: Alessandro Zucchelli <alessandro.zucche...@bugseng.com> >>>>> --- >>>>> automation/eclair_analysis/ECLAIR/deviations.ecl | 11 +++++++++++ >>>>> 1 file changed, 11 insertions(+) >>>>> >>>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl >>>>> b/automation/eclair_analysis/ECLAIR/deviations.ecl >>>>> index 447c1e6661..9fa9a7f01c 100644 >>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >>>>> @@ -487,6 +487,17 @@ leads to a violation of the Rule are deviated." >>>>> # Series 21. >>>>> # >>>>> >>>>> +-doc_begin="Rules 21.1 and 21.2 report identifiers reserved for the C >>>>> and POSIX >>>>> +standard libraries: if these libraries are not used there is no reason >>>>> to avoid such >>>>> +identifiers. All xen's translation units are compiled with option >>>>> -nostdinc, >>>>> +this guarantees that these libraries are not used. Some compilers could >>>>> perform >>>>> +optimization using built-in functions: this risk is partially addressed >>>>> by >>>>> +using the compilation option -fno-builtin. Builtins starting with >>>>> \"__builtin_\" >>>>> +still remain available." >>>> >>>> While the sub-section "Reserved Identifiers" is part of Section 7, >>>> "Library", close coordination is needed between the library and the >>>> compiler, which only together form an "implementation". Therefore any >>>> use of identifiers beginning with two underscores or beginning with an >>>> underscore and an upper case letter is at risk of colliding not only >>>> with a particular library implementation (which we don't use), but >>>> also of such with a particular compiler implementation (which we cannot >>>> avoid to use). How can we permit use of such potentially problematic >>>> identifiers? >>> >>> Alternative question: is there a way we can check if there is clash of >>> some sort between a compiler implementation of something and a MACRO or >>> identifier we have in Xen? An error or a warning from the compiler for >>> instance? That could be an easy way to prove we are safe. >> >> Well. I think it is the default for the compiler to warn when re-#define- >> ing a previously #define-d (by the compiler or by us) symbol, so on that >> side we ought to be safe at any given point in time, > > OK, that's good. It seems to me that this explanation should be part of > the deviation text. > > >> yet we're still latently unsafe (as to compilers introducing new >> pre-defines). > > Sure, but we don't need to be safe in relation to future compiler. Right > now, we are targeting gcc-12.1.0 as written in > docs/misra/C-language-toolchain.rst. When we decide to enable a new > compiler in Xen we can fix/change any specific define as needed. Also > note the large amount of things written in C-language-toolchain.rst that > need to be checked and verified for a new compiler to make sure we can > actually use it safely (we make many assumptions). > > >> For built-in declarations, though, there's nothing I'm aware of that >> would indicate collisions. > > For builtins, Alessandro was suggesting -fno-builtin. One question to > Alessandro is why would -fno-builtin only "partially" address the > problem. > > Another question for Jan and also Alessandro: given that builtins > starting with __builtin_ remain available, any drawbacks in using > -fno-builtin in a Xen build?
Just to mention it - we're building with -fno-builtin already anyway. What I'm puzzled by is that it looks like I was under the wrong impression that we're actually building -ffreestanding (which implies -fno-builtin). Jan
