2 ms·

I agree. I'm not sure breaking the ABI to fix the unwinder serialization issue should be a show-stopper, considering that there still isn't a C++ ABI.

gpderetta 5y ago
There are platform specific ABIs and there have been for many years. Many platforms want to preserve the ABI at all costs. In any case this doesn't seem to be an ABI issue
- cryptonector 5y ago
  I would think it shouldn't be an ABI issue, but maybe part of the unwinding code gets statically linked into shared objects?
gumby 5y ago
Th problem is that the corpus of deployed libraries is a de facto ABI. Even with dylib versioning, catching the case of API version is hard. I think it could be done by changing the mangling algorithm (basically: compile fails if new-ABI versions are not available) but I haven't thought enough about it to remove the words "I think" from the beginning of the sentence.
- atq2119 5y ago
  Since this is about immutable "side car" data structures used during unwinding: could this be achieved using a soft ABI transition as opposed to a hard, flag day ABI break? Basically, going forward the compiler would emit two versions of the unwinding tables by default: the legacy one and the one that allows fixing the thread contention issue. The unwinder is changed to use the efficient version by default with the ability to fall back to locking if it encounters a shared object that only has the old version. Space conscious users could choose to emit only one version by using a compiler flag, and after a decade or so the compiler is switched to only emit the new version by default (but the unwinder could retain the capability to understand the old format for a few decades longer). It seems like most of the table contents should even be shareable between versions? The locking seems to be only there to guard against shared object loading/unloading which should only affect the topmost level of the data structure. Admittedly I have no idea how those tables are actually defined today.
  - gumby 5y ago
    That might work. It would be yet another thing that would slow down compilation (link phase in this case) but not the worst. Compilers would have to generate both forms forever (except for new architectures) but probably that wouldn’t be terrible.
    - atq2119 5y ago
      It only took ~two decades to remove a.out support from the Linux kernel :) (I wonder when software engineers will more commonly think about their work on a generational time scale. Like how the cathedral builders of old must have thought about their work...)

gpderetta 5y ago

There are platform specific ABIs and there have been for many years. Many platforms want to preserve the ABI at all costs. In any case this doesn't seem to be an ABI issue

cryptonector 5y ago
I would think it shouldn't be an ABI issue, but maybe part of the unwinding code gets statically linked into shared objects?

gumby 5y ago

Th problem is that the corpus of deployed libraries is a de facto ABI. Even with dylib versioning, catching the case of API version is hard. I think it could be done by changing the mangling algorithm (basically: compile fails if new-ABI versions are not available) but I haven't thought enough about it to remove the words "I think" from the beginning of the sentence.

atq2119 5y ago
Since this is about immutable "side car" data structures used during unwinding: could this be achieved using a soft ABI transition as opposed to a hard, flag day ABI break? Basically, going forward the compiler would emit two versions of the unwinding tables by default: the legacy one and the one that allows fixing the thread contention issue. The unwinder is changed to use the efficient version by default with the ability to fall back to locking if it encounters a shared object that only has the old version. Space conscious users could choose to emit only one version by using a compiler flag, and after a decade or so the compiler is switched to only emit the new version by default (but the unwinder could retain the capability to understand the old format for a few decades longer). It seems like most of the table contents should even be shareable between versions? The locking seems to be only there to guard against shared object loading/unloading which should only affect the topmost level of the data structure. Admittedly I have no idea how those tables are actually defined today.
- gumby 5y ago
  That might work. It would be yet another thing that would slow down compilation (link phase in this case) but not the worst. Compilers would have to generate both forms forever (except for new architectures) but probably that wouldn’t be terrible.
  - atq2119 5y ago
    It only took ~two decades to remove a.out support from the Linux kernel :) (I wonder when software engineers will more commonly think about their work on a generational time scale. Like how the cathedral builders of old must have thought about their work...)