Add version indicators to rtld.

[kib]

Summary

It is wrong to relate on __FreeBSD_version, either from include/param.h, kernel, or libc, to check for rtld features. Rtld might be from newer world than the running userspace.

Add special private symbols exported by rtld itself, to indicate the changes in runtime behavior, and features that cannot be otherwise detected at runtime.

Note that the symbols are not exported from libc, consumers are required to use dlsym(3). For instance, for _rtld_version_laddr_offset, user should do

ptr = dlsym(RTLD_DEFAULT, "_rtld_version_laddr_offset")

or even

ptr = dlvsym(RTLD_DEFAULT,  "_rtld_version_laddr_offset", "FBSDprivate_1.0");

Non-null ptr means that the change is present.

[kib]

Fix warning.

[jhb]

I think this is ok, and GDB can use this to adjust in the future if needed. Part of me would like to just have a single version number that gets bumped, but perhaps having per-feature variables will be more scalable in the future. I honestly don't know the right answer. One "benefit" from having, say, a _rtld_version that was defined to __FreeBSD_version at compile time for rtld itself is that it can sometimes give you a way to handle breakages retroactively when you didn't realize a change would impact consumers. It might not hurt to perhaps provide _rtld_version as well as a similar symbol that could be used as a fallback for those types of cases. The use cases for it would indeed be extremely rare, but it is also very cheap to have around. We would include a comment saying that per-feature variables are the preferred method for communicating "known" breakages and that _rtld_version is only present for use as a fallback.

[jhb]

Hmm, perhaps the compiled version is already present in an ABI tag ELF note in which case you can ignore all my thoughts on _rtld_version

[kib]

In D24982#550477, @jhb wrote:

I think this is ok, and GDB can use this to adjust in the future if needed. Part of me would like to just have a single version number that gets bumped, but perhaps having per-feature variables will be more scalable in the future. I honestly don't know the right answer. One "benefit" from having, say, a _rtld_version that was defined to __FreeBSD_version at compile time for rtld itself is that it can sometimes give you a way to handle breakages retroactively when you didn't realize a change would impact consumers. It might not hurt to perhaps provide _rtld_version as well as a similar symbol that could be used as a fallback for those types of cases. The use cases for it would indeed be extremely rare, but it is also very cheap to have around. We would include a comment saying that per-feature variables are the preferred method for communicating "known" breakages and that _rtld_version is only present for use as a fallback.

I do not see how single version number is useful, mostly because of MFC. We merge back only some features, and sometimes do it in non-chronological order, so any consumer should be aware of map between rtld_version and features on each branch. So if I there is some future ABI-important feature that is merged to stable/12 before l_addr change, checking for it with just rtld_version becomes very convoluted.

In D24982#550480, @jhb wrote:

Hmm, perhaps the compiled version is already present in an ABI tag ELF note in which case you can ignore all my thoughts on _rtld_version

rtld is dso, so there is no note embedded.

[jhb]

In D24982#550500, @kib wrote:

In D24982#550477, @jhb wrote:

I think this is ok, and GDB can use this to adjust in the future if needed. Part of me would like to just have a single version number that gets bumped, but perhaps having per-feature variables will be more scalable in the future. I honestly don't know the right answer. One "benefit" from having, say, a _rtld_version that was defined to __FreeBSD_version at compile time for rtld itself is that it can sometimes give you a way to handle breakages retroactively when you didn't realize a change would impact consumers. It might not hurt to perhaps provide _rtld_version as well as a similar symbol that could be used as a fallback for those types of cases. The use cases for it would indeed be extremely rare, but it is also very cheap to have around. We would include a comment saying that per-feature variables are the preferred method for communicating "known" breakages and that _rtld_version is only present for use as a fallback.

I do not see how single version number is useful, mostly because of MFC. We merge back only some features, and sometimes do it in non-chronological order, so any consumer should be aware of map between rtld_version and features on each branch. So if I there is some future ABI-important feature that is merged to stable/12 before l_addr change, checking for it with just rtld_version becomes very convoluted.

As I said, I think it should be "both" with the version number to be a fallback for the case that a change gets made (and possibly MFC'd) where the author doesn't _realize_ at the time that it breaks some assumption used by some other tool. The FreeBSD_version values won't be perfect, but it will give some sort of bounds to use as a fallback for those cases if they arise. I think in the case where we make a change that we know will impact consumers, we use an explicit variable as you are doing here. I view _rtld_version as a fallback for the "oh crap, I didn't know any other software cared about that". It relies on the fact that other changes and MFCs will periodically bump FreeBSD_version that can be piggybacked on.

[kib]

Add _rtld_version__FreeBSD_version.

[jhb]

Thanks