[PATCH] x86: Don't remove empty x86 properties

Cary Coutant ccoutant@gmail.com
Wed Nov 28 07:45:00 GMT 2018


> 3 kinds of properties provide answers for different questions:
>
> 1. AND:  Do all input relocatables have the feature?
> 2. OR:  Does any input relocatables have the feature?
> 3. OR_AND:  Do all input relocatables have the property and
> some inputs have the feature? In turn, it can tell if none of input
> relocatables have the feature.
>
> It works better to keep both OR and OR_AND.

You can tell if none of the input relocatables have the feature only
if *all* of the input relocatables have the property. If even one of
the input relocatables is missing the property, you lose all the
feature bits -- you're discarding potentially useful information.
Remember, all the 1 bits are trustworthy even if a relocatable is
missing the property; it's the 0 bits that might not be accurate
(i.e., some of them might have been 1, depending on features used by
the objects missing the property info).

So now what do you expect the loader to do with the information in the
property note? If you have feature bits, presumably it will compare
the 1 bits with the available features on the hardware, and refuse to
run the program if its demands exceed the available features. And it
could give a meaningful error message explaining exactly which
features are required but not available.

But what if you've removed the property entirely? Should the loader
refuse to run the program? No, you're going to want it to run anyway,
right? And it'll fail at run time if it tries to use an unavailable
feature. But if you hadn't thrown away those 1 bits, you could still
get a meaningful error message for the features we do know about. A
single new AND bit (or a version number) will tell you the same thing
that a missing property tells you, without throwing away all those
useful bits of information.

-cary



More information about the Binutils mailing list