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

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.

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.