Re: BUG #18899: FreeBSD, assembly by means of GCC with ASAN ends with error: undef reference to backtrace_symbols_fd
От | Tom Lane |
---|---|
Тема | Re: BUG #18899: FreeBSD, assembly by means of GCC with ASAN ends with error: undef reference to backtrace_symbols_fd |
Дата | |
Msg-id | 2638884.1744997930@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18899: FreeBSD, assembly by means of GCC with ASAN ends with error: undef reference to backtrace_symbols_fd (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > With ASAN, configtest.c is built without the need for some additional > libraries, because `backtrace_symbols' defined in > /usr/local/lib/gcc13/libasan.so.8. > $ nm -D /usr/local/lib/gcc13/libasan.so.8 | grep backtrace_symbols > 000000000007e6c0 T __interceptor_backtrace_symbols > 000000000007e6c0 T backtrace_symbols Isn't this a flat-out bug/oversight in libasan? It's hard to believe that they have a reason for overriding backtrace_symbols that would not also apply to backtrace_symbols_fd. Nor that it's a good idea to risk applications seeing different behaviors from those functions. > This corrects the problem for me: > -AC_SEARCH_LIBS(backtrace_symbols, execinfo) > +AC_SEARCH_LIBS(backtrace_symbols_fd, execinfo) I do not love this fix. It's certainly arguable that we shouldn't assume that backtrace_symbols_fd is available just because backtrace_symbols is, but the reverse assumption is not much better. If we were to do anything about this, I think what it ought to be is to make separate configure probes for the two functions and then have assert.c say "#ifdef HAVE_BACKTRACE_SYMBOLS_FD". But on the whole I think this is libasan's problem not ours. While you're waiting for them to fix it you could just manually add LDFLAGS=-lexecinfo in ASAN builds. regards, tom lane
В списке pgsql-bugs по дате отправления: