Hi Palmer,

The 64-bit RISC-V Linux port has a minimum of 39-bit virtual addresses, so it 
should be 1<<36 for 64-bit targets. In the implementation of address sanitizer, 
we need a shadow memory that is 1/8th of the memory size, which is
where the 36 comes from. I don't think the choice of this value is arbitrary. 

Jun
------------------------------------------------------------------
发件人:Palmer Dabbelt <pal...@dabbelt.com>
发送时间:2020年8月21日(星期五) 00:04
收件人:gcc-patches <gcc-patches@gcc.gnu.org>
抄 送:Kito Cheng <kito.ch...@gmail.com>; Andrew Waterman <and...@sifive.com>; 
gcc-patches <gcc-patches@gcc.gnu.org>; cooper.joshua 
<cooper.jos...@linux.alibaba.com>
主 题:Re: [RISC-V] Add support for AddressSanitizer on RISC-V GCC

On Wed, 19 Aug 2020 02:25:37 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> Hi Andrew:
>
> I am not sure the reason why some targets pick different numbers.
> It seems it's not only target dependent but also OS dependent[1].
>
> For RV32, I think using 1<<29 like other 32 bit targets is fine.
>
> [1] 
> https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/asan/asan_mapping.h#L159
>
> Hi Joshua:
>
> Could you update that for RV32, and this patch will be pending until
> LLVM accepts the libsanitizer part.

This is ABI, and Linux only supports kasan on rv64 right now so it's
technically undefined.  It's probably best to avoid picking an arbitrary number
for rv32, as we still have some open questions WRT the kernel memory map over
there.  I doubt that will get sorted out for a while, as the rv32 doesn't get a
lot of attention (though hopefully the glibc stuff will help out).

> On Wed, Aug 19, 2020 at 4:48 PM Andrew Waterman <and...@sifive.com> wrote:
>>
>> I'm having trouble understanding why different ports chose their
>> various constants--e.g., SPARC uses 1<<29 for 32-bit and 1<<43 for
>> 64-bit, whereas x86 uses 1<<29 and 0x7fff8000, respectively.  So I
>> can't comment on the choice of the constant 1<<36 for RISC-V.  But
>> isn't it a problem that 1<<36 is not a valid Pmode value for ILP32?

This is for kasan (not regular asan), which requires some coordination between
the kernel's memory map and the compiler's inline address sanitizer (as you
can't just pick your own memory map).  Essentially what's going on is that
there's an array of valid tags associated with each address, which is checked
in-line by the compiler for performance reasons (IIRC it used to be library
routines).  The compiler needs to know how to map between addresses and tags,
which depends on the kernel's memory map -- essentially baking the kernel's
memory map into the compiler.  That's why the constants seem somewhat
arbitrary.

In order to save memory there's some lossyness in the address->tag mapping.
Most 32-bit ports pick a tag array that's 1/8th of the memory size, which is
where the 29 comes from.  I don't see any reason why that wouldn't be workable
on rv32, but it seems better to make sure that's the case rather than just
making up an ABI :)

>> On Wed, Aug 19, 2020 at 1:02 AM Joshua via Gcc-patches
>> <gcc-patches@gcc.gnu.org> wrote:
>> >
>> > From: cooper.joshua <cooper.jos...@linux.alibaba.com>
>> >
>> >     gcc/
>> >
>> >         * config/riscv/riscv.c (asan_shadow_offset): Implement the offset 
>> > of asan shadow memory for risc-v.
>> >         (asan_shadow_offset): new macro definition.
>> > ---
>> >
>> >  gcc/config/riscv/riscv.c | 11 +++++++++++
>> >  1 file changed, 11 insertions(+)
>> >
>> > diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
>> > index 63b0c38..b85b459 100644
>> > --- a/gcc/config/riscv/riscv.c
>> > +++ b/gcc/config/riscv/riscv.c
>> > @@ -5292,6 +5292,14 @@ riscv_gpr_save_operation_p (rtx op)
>> >    return true;
>> >  }
>> >
>> > +/* Implement TARGET_ASAN_SHADOW_OFFSET.  */
>> > +
>> > +static unsigned HOST_WIDE_INT
>> > +riscv_asan_shadow_offset (void)
>> > +{
>> > +  return HOST_WIDE_INT_1U << 36;
>> > +}
>> > +
>> >  /* Initialize the GCC target structure.  */
>> >  #undef TARGET_ASM_ALIGNED_HI_OP
>> >  #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
>> > @@ -5475,6 +5483,9 @@ riscv_gpr_save_operation_p (rtx op)
>> >  #undef TARGET_NEW_ADDRESS_PROFITABLE_P
>> >  #define TARGET_NEW_ADDRESS_PROFITABLE_P riscv_new_address_profitable_p
>> >
>> > +#undef TARGET_ASAN_SHADOW_OFFSET
>> > +#define TARGET_ASAN_SHADOW_OFFSET riscv_asan_shadow_offset
>> > +
>> >  struct gcc_target targetm = TARGET_INITIALIZER;
>> >
>> >  #include "gt-riscv.h"
>> > --
>> > 2.7.4
>> >

Reply via email to