Date: Fri, 29 Apr 2022 17:13:37 -0400
On 4/29/22 4:40 PM, Daniel Ruoso wrote:
> Em sex., 29 de abr. de 2022 às 12:45, Tom Honermann
> <tom_at_[hidden]> escreveu:
>> I think compiler options can be effectively ignored in determining whether a previously built BMI is compatible if we have the following information available:
>> The language standard used to build the BMI.
>> The ABI (or at least the data model governing type sizes, type alignments, layout, etc...).
>> The (predefined) macros that were consulted when building the BMI. E.g., in a build for which f() returns 2, ONE_THING must not have been predefined, GOTTA_BE had to be predefined, and ANOTHER doesn't matter.
>> The attribute availability checks that were performed. E.g., in a build for which f() returns 4, the deprecated attribute must have been available, but carries_dependency doesn't matter.
>> The header file checks that were performed. E.g., in a build for which f() returns 5, a "thing.h" header file must have been available, but other header files don't matter.
> That doesn't match what current implementations are doing.
I'm not sure how to interpret your response here.
Internally, Clang supports listeners or callbacks that can observe
preprocessing decisions as they are made. This could be used to record
what "environmental" properties were relevant while parsing the MIU
(I've written tools that do this in the past). I don't know if other
compilers have such capabilities at present; I suspect MSVC might with
its new preprocessor implementation. At any rate, instrumenting a
preprocessor to record its conditional code inclusion decisions and use
of predefined macros seems likely to be feasible to me.
>
> Both clang and gcc have the compatibility of the binary module
> interface file limited to the specific version of the compiler, I even
> heard that different builds of the same version may end up with
> different formats too. And even MSVC has different versions of the IFC
> file, and therefore before consuming a BMI you have to know if this
> particular version of the compiler knows how to parse that particular
> version of the IFC file.
Yes, I forgot to mention the compiler and compiler version dependency
information; that would have to be included as well.
The example also failed to include an example of a (predefined) macro
expansion occurring in the source code; those dependencies would have to
be included as well.
Are there others that I missed?
Tom.
>
> daniel
> Em sex., 29 de abr. de 2022 às 12:45, Tom Honermann
> <tom_at_[hidden]> escreveu:
>> I think compiler options can be effectively ignored in determining whether a previously built BMI is compatible if we have the following information available:
>> The language standard used to build the BMI.
>> The ABI (or at least the data model governing type sizes, type alignments, layout, etc...).
>> The (predefined) macros that were consulted when building the BMI. E.g., in a build for which f() returns 2, ONE_THING must not have been predefined, GOTTA_BE had to be predefined, and ANOTHER doesn't matter.
>> The attribute availability checks that were performed. E.g., in a build for which f() returns 4, the deprecated attribute must have been available, but carries_dependency doesn't matter.
>> The header file checks that were performed. E.g., in a build for which f() returns 5, a "thing.h" header file must have been available, but other header files don't matter.
> That doesn't match what current implementations are doing.
I'm not sure how to interpret your response here.
Internally, Clang supports listeners or callbacks that can observe
preprocessing decisions as they are made. This could be used to record
what "environmental" properties were relevant while parsing the MIU
(I've written tools that do this in the past). I don't know if other
compilers have such capabilities at present; I suspect MSVC might with
its new preprocessor implementation. At any rate, instrumenting a
preprocessor to record its conditional code inclusion decisions and use
of predefined macros seems likely to be feasible to me.
>
> Both clang and gcc have the compatibility of the binary module
> interface file limited to the specific version of the compiler, I even
> heard that different builds of the same version may end up with
> different formats too. And even MSVC has different versions of the IFC
> file, and therefore before consuming a BMI you have to know if this
> particular version of the compiler knows how to parse that particular
> version of the IFC file.
Yes, I forgot to mention the compiler and compiler version dependency
information; that would have to be included as well.
The example also failed to include an example of a (predefined) macro
expansion occurring in the source code; those dependencies would have to
be included as well.
Are there others that I missed?
Tom.
>
> daniel
Received on 2022-04-29 21:13:40