This is an archive of the discontinued LLVM Phabricator instance.

[test][tsan] Remove weak, they are from headers now
Changes PlannedPublic

Authored by vitalybuka on Mar 20 2023, 4:28 PM.

Diff Detail

Event Timeline

vitalybuka created this revision.Mar 20 2023, 4:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 20 2023, 4:28 PM
Herald added a subscriber: Enna1. · View Herald Transcript
vitalybuka requested review of this revision.Mar 20 2023, 4:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 20 2023, 4:28 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
dvyukov edited reviewers, added: kubamracek, yln; removed: dvyukov.Mar 21 2023, 1:14 AM
dvyukov added a subscriber: dvyukov.

Remove weak, they are from headers now

Should 'weak' be in interface headers?
All user definitions of the callbacks must be non-weak to override our weak definitions, and the interface header is for users.

Remove weak, they are from headers now

Should 'weak' be in interface headers?
All user definitions of the callbacks must be non-weak to override our weak definitions, and the interface header is for users.

If we add weak tsan_default_options/tsan_default_suppressions it may break existing users who included the header and provided non-weak versions. Now they suddenly define weak ones that don't override ours.

@rsundahl Do you thing it's going to work with D146469 ?

Thanks for including me @vitalybuka... To understand why these tests have the conditional code making the overrides "weak" please see https://reviews.llvm.org/D127929 (show older changes) for the discussion. To summarize here though:
The idea of a "strong" overriding "weak" symbols is reasonably well understood and iirc is specified by the standard(s) but only in the context of static linking. The problem is complicated with dynamic linking. For a worst case thought experience, think about what should happen to weakly bound symbols when an application calls dlopen() on a dll that contains possible overrides or additional weak symbols. dyld uses two-level name space linking which essentially precludes a strong symbol in a different module from ever replacing a weak symbol, but it has a slight variation on this behavior in that during this "weak-def coalescing", it does consider any other modules containing weak definitions. The weak attributes on the "overrides" in the tests above are there only to cause the module (the test program) to be considered during weak-def coalescing at which time the weak symbol in the test program overrides the weak symbol reference from the dll. Yes, in this case it's a weak overriding a weak but with dyld the way to think of it is that if a symbol is marked weak, then all definitions of that symbol are treated as weak during weak-def coalescing. It would be just as effective to define a dummy unused weak symbol in the test program:

__attribute__((weak)) int foo;

This too would mark the dll as having a weak symbol and so then all the symbols in the test program would be seen during weak-def coalescing.

rsundahl added a subscriber: thetruestblue.

@rsundahl Do you thing it's going to work with D146469 ?

I'm not sure exactly what you're asking vis-a-vis https://reviews.llvm.org/D146469 @vitalybuka but I think it's a subtlety. Could you elaborate? I'm adding @thetruestblue as she has been working recently on these interceptors and may spot something that I don't.

vitalybuka planned changes to this revision.Mar 21 2023, 9:38 AM

@rsundahl Do you thing it's going to work with D146469 ?

Thanks for including me @vitalybuka... To understand why these tests have the conditional code making the overrides "weak" please see https://reviews.llvm.org/D127929 (show older changes) for the discussion. To summarize here though:
The idea of a "strong" overriding "weak" symbols is reasonably well understood and iirc is specified by the standard(s) but only in the context of static linking. The problem is complicated with dynamic linking. For a worst case thought experience, think about what should happen to weakly bound symbols when an application calls dlopen() on a dll that contains possible overrides or additional weak symbols. dyld uses two-level name space linking which essentially precludes a strong symbol in a different module from ever replacing a weak symbol, but it has a slight variation on this behavior in that during this "weak-def coalescing", it does consider any other modules containing weak definitions. The weak attributes on the "overrides" in the tests above are there only to cause the module (the test program) to be considered during weak-def coalescing at which time the weak symbol in the test program overrides the weak symbol reference from the dll. Yes, in this case it's a weak overriding a weak but with dyld the way to think of it is that if a symbol is marked weak, then all definitions of that symbol are treated as weak during weak-def coalescing. It would be just as effective to define a dummy unused weak symbol in the test program:

__attribute__((weak)) int foo;

This too would mark the dll as having a weak symbol and so then all the symbols in the test program would be seen during weak-def coalescing.