| Message ID | 20200819080209.133-1-cooper.joshua@linux.alibaba.com |
|---|---|
| State | New |
| Headers | show |
| Series | [RISC-V] Add support for AddressSanitizer on RISC-V GCC | expand |
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? On Wed, Aug 19, 2020 at 1:02 AM Joshua via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > From: cooper.joshua <cooper.joshua@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 >
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. On Wed, Aug 19, 2020 at 4:48 PM Andrew Waterman <andrew@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? > > > On Wed, Aug 19, 2020 at 1:02 AM Joshua via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > > From: cooper.joshua <cooper.joshua@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 > >
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 <andrew@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.joshua@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 >> >
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 <palmer@dabbelt.com> 发送时间：2020年8月21日(星期五) 00:04 收件人：gcc-patches <gcc-patches@gcc.gnu.org> 抄 送：Kito Cheng <kito.cheng@gmail.com>; Andrew Waterman <andrew@sifive.com>; gcc-patches <gcc-patches@gcc.gnu.org>; cooper.joshua <cooper.joshua@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 <andrew@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.joshua@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 >> >
On Fri, Aug 21, 2020 at 12:04 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > 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). Yeah, I agree it's part of ABI, and I think this part could wait until rv32 glibc upstream, the day seems not too far. > > On Wed, Aug 19, 2020 at 4:48 PM Andrew Waterman <andrew@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. IIRC kasan will give the offset via -fasan-shadow-offset, so TARGET_ASAN_SHADOW_OFFSET only meaningful for (user-space) asan. > > 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 :) I guess we could try it after rv32 glibc upstream. > > >> On Wed, Aug 19, 2020 at 1:02 AM Joshua via Gcc-patches > >> <gcc-patches@gcc.gnu.org> wrote: > >> > > >> > From: cooper.joshua <cooper.joshua@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 > >> >
On Wed, Aug 19, 2020 at 1:02 AM Joshua via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > * config/riscv/riscv.c (asan_shadow_offset): Implement the offset of asan shadow memory for risc-v. > (asan_shadow_offset): new macro definition. When I try the patch, I get asan errors complaining about memory mappings. ==9422==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ==9422==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range. I haven't gotten it working yet, but I haven't tried debugging it yet either. How exactly are you testing it? It fails for me using a 4.15 kernel on hardware, and on a user mode qemu. I haven't tried booting a 5.x kernel in qemu, that would take some time to set up. Likewise using a 5.x kernel on hardware would take some time to set up. Jim
On Tue, Aug 25, 2020 at 12:39 PM Jim Wilson <jimw@sifive.com> wrote: > On Wed, Aug 19, 2020 at 1:02 AM Joshua via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > * config/riscv/riscv.c (asan_shadow_offset): Implement the offset of asan shadow memory for risc-v. > > (asan_shadow_offset): new macro definition. > > When I try the patch, I get asan errors complaining about memory mappings. I tried looking at this again today. I spent a few hours debugging sanitizer code to see what is going on, and managed to convince myself that the patch can't possibly work for riscv64-linux. There are at least two changes missing. It also can't possibly work for riscv32-linux. There is at least one change missing. libsanitizer/configure.tgt only supports riscv64-linux, so nothing gets built for riscv32-linux. I have no idea how you got this working. Maybe you forgot to send the entire patch? If there is a way to get it working, it would be good if you could describe in detail how you got it working. For riscv64-linux with these additional patches hifiveu017:1192$ more tmp.file diff --git a/libsanitizer/asan/asan_mapping.h b/libsanitizer/asan/asan_mapping.h index 09be904270c..906fb1eebc8 100644 --- a/libsanitizer/asan/asan_mapping.h +++ b/libsanitizer/asan/asan_mapping.h @@ -164,6 +164,7 @@ static const u64 kAArch64_ShadowOffset64 = 1ULL << 36; static const u64 kMIPS32_ShadowOffset32 = 0x0aaa0000; static const u64 kMIPS64_ShadowOffset64 = 1ULL << 37; static const u64 kPPC64_ShadowOffset64 = 1ULL << 41; +static const u64 kRISCV64_ShadowOffset64 = 1ULL << 36; static const u64 kSystemZ_ShadowOffset64 = 1ULL << 52; static const u64 kSPARC64_ShadowOffset64 = 1ULL << 43; // 0x80000000000 static const u64 kFreeBSD_ShadowOffset32 = 1ULL << 30; // 0x40000000 @@ -210,6 +211,8 @@ static const u64 kMyriadCacheBitMask32 = 0x40000000ULL; # define SHADOW_OFFSET kAArch64_ShadowOffset64 # elif defined(__powerpc64__) # define SHADOW_OFFSET kPPC64_ShadowOffset64 +# elif defined(__riscv) && (__riscv_xlen == 64) +# define SHADOW_OFFSET kRISCV64_ShadowOffset64 # elif defined(__s390x__) # define SHADOW_OFFSET kSystemZ_ShadowOffset64 # elif SANITIZER_FREEBSD diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cpp b/libsanitizer/sa nitizer_common/sanitizer_linux.cpp index 11c03e286dc..962df07772e 100644 --- a/libsanitizer/sanitizer_common/sanitizer_linux.cpp +++ b/libsanitizer/sanitizer_common/sanitizer_linux.cpp @@ -1048,6 +1048,8 @@ uptr GetMaxVirtualAddress() { return (1ULL << (MostSignificantSetBitIndex(GET_CURRENT_FRAME()) + 1)) - 1; # elif defined(__mips64) return (1ULL << 40) - 1; // 0x000000ffffffffffUL; +# elif defined(__riscv) && (__riscv_xlen == 64) + return (1ULL << 39) - 1; // 0x0000008000000000UL; # elif defined(__s390x__) return (1ULL << 53) - 1; // 0x001fffffffffffffUL; #elif defined(__sparc__) hifiveu017:1193$ I now get ==2936470==AddressSanitizer CHECK failed: ../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:76 "((kSpaceBeg)) == ((address_range.Init(TotalSpaceSize, PrimaryAllocatorName, kSpaceBeg)))" (0x600000000000, 0xffffffffffffffff) <empty stack> so there is still something missing but I think I am closer. Jim
On 8/19/20 11:25 AM, Kito Cheng via Gcc-patches wrote: > Could you update that for RV32, and this patch will be pending until > LLVM accepts the libsanitizer part. Hello. I've noticed that the libsanitizer part was accepted to LLVM. I'm planning to do a merge upstream (for libsanitizer) and was planning to do so in 3 weeks. I can do it earlier if it helps for the integration and testing purpose? Thoughts? Thanks, Martin
Hi Martin: > I can do it earlier if it helps for the integration and testing purpose? I think it would be helpful! thanks! On Fri, Oct 16, 2020 at 3:33 PM Martin Liška <mliska@suse.cz> wrote: > > On 8/19/20 11:25 AM, Kito Cheng via Gcc-patches wrote: > > Could you update that for RV32, and this patch will be pending until > > LLVM accepts the libsanitizer part. > > Hello. > > I've noticed that the libsanitizer part was accepted to LLVM. I'm planning to do > a merge upstream (for libsanitizer) and was planning to do so in 3 weeks. > > I can do it earlier if it helps for the integration and testing purpose? > > Thoughts? > Thanks, > Martin
On 10/16/20 9:45 AM, Kito Cheng wrote:
> I think it would be helpful! thanks!
Hello.
I've just installed the patches to master.
Martin
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"
From: cooper.joshua <cooper.joshua@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(+)