This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fix ASAN failures on SPARC64/Linux
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 13 Mar 2019 10:58:41 +0100
- Subject: Re: [patch] Fix ASAN failures on SPARC64/Linux
- References: <4930863.as9yYVlIhr@polaris> <20190313093059.GZ7611@tucnak>
> Is the size of the virtual address space hole constant though (and will it
> remain constant)?
The kernel sources say that it's constant and with this position for SPARC-T4
and later. It's different (larger hole) for SPARC-T3 and earlier but I cannot
really test. I don't think that it will change for a given processor.
> E.g. on powerpc64 or aarch64 there are in each case like 4-5 different VA
> size configurations over the last 10+ years of kernel history and
> configuration options and fortunately all that is hidden inside of libasan,
> if you have older gcc and run into an unsupported VA configuration, all it
> takes is update libasan to one that supports it and binaries continue to
> work.
But a few targets have hardcoded VA size in TARGET_ASAN_SHADOW_OFFSET too.
> Could libasan initialization if it detects just PROT_NONE mmap from the end
> of hole to the start of the region it really supports (and fail if that
> fails), so that backward compatibility is ensured?
I'll investigate how targets supporting multiple VA size behave, but I don't
have access to a large range of SPARC machines...
> Also, don't you need some corresponding libsanitizer changes?
Of course, just merged.
--
Eric Botcazou