Re: Silencing upcoming warning about stack_base_ptr

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Silencing upcoming warning about stack_base_ptr
Дата
Msg-id 20220218001255.cb566si23kq5f64r@alap3.anarazel.de
обсуждение исходный текст
Ответ на Silencing upcoming warning about stack_base_ptr  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Silencing upcoming warning about stack_base_ptr  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2022-02-17 18:44:27 -0500, Tom Lane wrote:
> (that's visible now on buildfarm member caiman).  We probably
> should take some thought for silencing this before it starts
> to be in people's faces during routine development.

Agreed.

One annoying thing I recently encountered, related to this, is that our stack
check fails to work with some -fsanitize* options because they end up using
multiple stacks (e.g. -fsanitize-address-use-after-scope). Not sure we can
really do anything about that...


> Fixing this is a bit harder than one could wish because we export
> set_stack_base() for use by PL/Java, so it would be better to not
> change that API.  I ended up with the attached patch, which works
> to silence the warning so long as the new subroutine
> set_stack_base_from() is marked pg_noinline.  I'm a little worried
> that in a year or two GCC will be smart enough to complain anyway.
> If that happens, we could probably silence the warning again by
> moving set_stack_base() to a different source file --- but at some
> point we might have to give up and change its API, I suppose.

We could try using __builtin_frame_address(0) when available, presumably gcc
won't warn about that...

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Silencing upcoming warning about stack_base_ptr
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM