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
> 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)
> >
> 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)
>
> 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
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
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
> 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
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
Hi,
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
fix has been accepted upstream, along with other fixes for
10 matches
Mail list logo
