https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Yuri Gribov from comment #5) > (In reply to Martin Liška from comment #4) > > I'm pasting here Jakub's opinion which I agree with: > > > > ``` > > I'm strongly against the blacklist, that is not the way things are done in > > GCC, you have corresponding attribute to mark functions you don't want to > > instrument, people can macroize that with > > __typeof (symbol) symbol __attribute__((__no_sanitize_address__)); > > But in any case, you mark it in the code rather than adding externally > > some symbol list. > > Well, blacklists simplify integration of Asan to large codebases (e.g. full > Linux distro) where you often don't have the luxury of modifying the source > code. I believe was the main reason why they were added to Clang's sanitizer. > > Just to double check, what are the technical arguments against using > blacklists? The problem is that strings can't uniquely identify all functions. Either the strings are mangled names, but then you can only use that to identify the exported functions (and even then, for say comdat functions you can only affect all of them or none), stuff like functions in anonymous namespaces, methods in local types and the like are not accessible this way. Or you use non-mangled names and then it is even fuzzier on what you identify. I know there is #pragma weak supported for compatibility with something that also uses similar kind of symbol matching, but IMNSHO it is equally misdesigned thing.
