On Tue, Dec 10, 2013 at 12:10 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Dec 10, 2013 at 12:06:55PM +0400, Yury Gribov wrote: >> > 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. >> >> I think the functionality in question is not specific for Asan. In >> general it may be useful to allow control of compiler options at >> intra-file level with the help of external config >> (blacklist file in this case). I can imagine situations where people >> would prefer to avoid changing their codes and simply throw in a >> config. As Kostya pointed out you sometimes can't change 3rd party >> codes. > > You can still -include some header file from the command line and put the > attributes in there or similar. The blacklist is really terribly ugly hack, > which can't work reliably. What do you do for anonymous namespaces? For > not exported functions? Identifying externally decls by name is > problematic, without mangled names very problematic, with mangled names not > useful for symbols that are local to the TU.
Our blacklist format supports not just function names, but also files names and any other arbitrary entity. E.g. in asan we have to blacklist globals by their type name from init-order-checking. https://code.google.com/p/address-sanitizer/wiki/InitializationOrderFiasco All of this is a bit ugly. But we have no other mechanism that works today. --kcc > > Jakub
