public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "tao.zeng@amlogic.com" <tao.zeng@amlogic.com>
To: "Martin Liška" <mliska@suse.cz>, gcc <gcc@gcc.gnu.org>
Cc: Jakub Jelinek <jakub@redhat.com>
Subject: Re: Re: About -fasan-shadow-offset option
Date: Sat, 26 Nov 2022 09:29:07 +0800	[thread overview]
Message-ID: <202211260929073075775@amlogic.com> (raw)
In-Reply-To: <f62c638c-2662-535e-f73d-1ee14483b3e5@suse.cz>

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

Dear Martin Liška

    Thanks for your research. I have resolved this problem by pass a ddrsize paramters when build and cacluate the offset used by -fasan-shadow-offset according that parameter. 



Thanks!
B.R.
Tao.Zeng@amlogic.com
 
Address: Building E5, 2555 Xiupu Road, Pudong District, Shanghai, China
公司地址:上海市浦东新区秀浦路2555号漕河泾康桥商务绿洲E5栋

 
发件人: Martin Liška
发送时间: 2022-11-26 00:23
收件人: tao.zeng@amlogic.com; gcc
抄送: Jakub Jelinek
主题: Re: About -fasan-shadow-offset option
 
[ EXTERNAL EMAIL ]
 
On 11/16/22 10:01, tao.zeng@amlogic.com wrote:
> Dear gcc:
> 
 
Hello.
 
Based on quick discussion with Jakub, we believe fasan-shadow-symbol=xxxx would be a non-trivial amount of work
and we rather suggest doing a per-system build with investigated -fasan-shadow-offset.
 
Cheers,
Martin
 
>     I am developing a address sanitiser tools for u-boot. Basically refers compile options from kernel side. But there is a problem that I must set -fasan-shadow-offset with a pre-calculated value. Otherwise GCC compiler will use 0x1000000000 as default value for shadow offset and caused boot failed because this value is too large.
>     The problem is uboot do not have a fixed memory layout as kernel. Basically it will relocate to end of DDR size and running at that memory space. Usually memory map for uboot is virt=phys and there are lots of drivers do not do address translate for dma based on this mapping. But ddr size are different on each platform. So it's hard to handle shadow offset at this scenario.
>     My point is that can gcc add an option like -fasan-shadow-symbol=xxxx, here xxxx is a global variable and implementors can configure it's value based on platforms ddr size/malloc buffer size during initialize stage and this variable can be used for shadow address calculation during runtime. This may be more fitable compared than a fixed value during compile stage.  And is there any other options to help my problem?
>     Waiting for your response asap.
>      Thanks.
> 
> 
> 
> Thanks!
> B.R.
> Tao.Zeng@amlogic.com
>  
> Address: Building E5, 2555 Xiupu Road, Pudong District, Shanghai, China
> 公司地址:上海市浦东新区秀浦路2555号漕河泾康桥商务绿洲E5栋
> 
 

      reply	other threads:[~2022-11-26  1:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16  9:01 tao.zeng
2022-11-25 16:23 ` Martin Liška
2022-11-26  1:29   ` tao.zeng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202211260929073075775@amlogic.com \
    --to=tao.zeng@amlogic.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=mliska@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).