This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [committed] Cherry-pick upstream asan fix for upcoming glibc (PR sanitizer/71160)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Maxim Ostapenko <m dot ostapenko at samsung dot com>, fweimer at redhat dot com
- Cc: gcc-patches at gcc dot gnu dot org, Kostya Serebryany <kcc at google dot com>, Yuri Gribov <tetra2005 at gmail dot com>
- Date: Tue, 17 May 2016 16:46:14 +0200
- Subject: Re: [committed] Cherry-pick upstream asan fix for upcoming glibc (PR sanitizer/71160)
- Authentication-results: sourceware.org; auth=none
- References: <20160517092323 dot GH28550 at tucnak dot redhat dot com> <573B2CE3 dot 3070705 at samsung dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, May 17, 2016 at 05:38:27PM +0300, Maxim Ostapenko wrote:
> Hi Jakub,
>
> thanks for backporting this! Do you have any plans to apply this patch to
> GCC 5 and 6 branches? AFAIK people hit on this ASan + newer Glibc bug by
> using GCC 5.3.1 on Fedora 23.
I don't have the newer glibc on my box, therefore I'm waiting until somebody
confirms the trunk change fixed it before backporting.
> >IMHO even better would be to make sure that in the common case (recent
> >glibc) we don't have failed dlsym calls (still, this hack is useful just in
> >case) - the __isoc99_*printf* interceptors make no sense, glibc has never
> >exported those. Thus, if we bump ABI of libasan again for GCC 7, IMHO those
> >bogus interceptors should be ifdefed out for glibc or removed completely.
> >Or, if we don't want to break ABI, at least changed so that they actuall
> >dlsym the corresponding *printf* (not __isoc99_ prefixed) functions
> >instead of the bogus ones.
>
> We should definitely bump libasan version on next libsanitizer merge,
> because it would contain ABI breaking changes in ASan. Perhaps we could
> ifdef these __isoc99 interceptors as a local GCC patch then?
Well, with the patch it is nothing urgent, but IMNSHO the bogus interceptors
aren't needed upstream either.
Jakub