On Thu, Mar 14, 2019 at 11:01:37PM +0100, Eric Botcazou wrote:
> > Not if the >> 3 shift is arithmetic shift.
>
> Sorry, I don't understand how this can work.
For some configurations, libasan defines SHADOW_OFFSET to
__asan_shadow_memory_dynamic_address (exported uptr symbol from libasan),
so SHA
> Not if the >> 3 shift is arithmetic shift.
Sorry, I don't understand how this can work.
--
Eric Botcazou
On Wed, Mar 13, 2019 at 12:21:15PM +0100, Eric Botcazou wrote:
> > So, when using the MemToShadow(addr) (1UL << 43) + ((addr << 12) >> (12 +
> > 3)) mapping, the first valid address above the hole will have shadow at:
> > 0x00020700UL (will not work, as it is inside of the VA hole)
> > 0x
> So, when using the MemToShadow(addr) (1UL << 43) + ((addr << 12) >> (12 +
> 3)) mapping, the first valid address above the hole will have shadow at:
> 0x00020700UL (will not work, as it is inside of the VA hole)
> 0x0001f800UL (will not work, as it is inside of the VA hole)
> 0
> It actually is something that works with all the VA sizes that are
> supported.
Well, there were changes in the past that seem to indicate that this has not
always been true but, of course, the very specific VM layout on SPARC 64-bit
(apparently inherited from Solaris) makes things much more c
On Wed, Mar 13, 2019 at 11:17:49AM +0100, Jakub Jelinek wrote:
> On Wed, Mar 13, 2019 at 10:58:41AM +0100, Eric Botcazou wrote:
> > > 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 p
On Wed, Mar 13, 2019 at 10:58:41AM +0100, Eric Botcazou wrote:
> > 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 SPAR
> 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 c
On Mon, Mar 11, 2019 at 11:29:39AM +0100, Eric Botcazou wrote:
> ASAN was enabled for the SPARC architecture during GCC 9 development but it
> doesn't really work on SPARC64/Linux because of the specific layout of the
> virtual memory address space. Fortunately this is (easily) fixable and the
