public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Arslan Khan <arslankhan52@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: How to insert reference to external symbol in RTL properly?
Date: Sun, 02 Jun 2019 05:05:00 -0000	[thread overview]
Message-ID: <CAE2e3sJjZi5Rd_E0a+m=CBoww_3Vduc1LYNymD9-Lg5ztxUMGg@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc3a4UufWPK5HZTJrP6uL037tYoXD-3KuJRHX_OpZnOWRA@mail.gmail.com>

Thanks for the pointer. That worked for me. I create the reference in
GIMPLE and then patch the assignments with LR register in the RTL
pass. Anyhow still i would like to know what should be the proper way
to do this entirely in RTL pass, is doing so not recommended? maybe
some piece of code that is already doing that?

Thanks,
Arslan

On Fri, May 31, 2019 at 4:37 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Wed, May 29, 2019 at 11:50 PM Arslan Khan <arslankhan52@gmail.com> wrote:
> >
> > Are you suggesting that i insert an extern at source level? Wouldn't
> > that decrease the usability of the safe stack drastically? Currently
> > all user has to do is provide an address where we intend to place
> > shadow stack, but if he has to place extern symbols in all using files
> > that would be cumbersome.
> > Besides that even i do that, is there a symbol table maintained by GCC
> > that i can use to access this in an RTL pass?
>
> I'm not suggesting to declare it at source level but you have to create
> and assemble it, see how tree-profile.c uses build_decl.
>
> Richard.
>
> > Thanks,
> > Arslan
> >
> > On Wed, May 29, 2019 at 3:17 AM Richard Biener
> > <richard.guenther@gmail.com> wrote:
> > >
> > > On Tue, May 28, 2019 at 1:01 AM Arslan Khan <arslankhan52@gmail.com> wrote:
> > > >
> > > > Hi,
> > > > I am a beginner to GCC and am trying to implement safe stack using a
> > > > GCC Plugin for embedded systems. I am using a cross compiler, with GCC
> > > > version:
> > > >
> > > > arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors
> > > > 6-2018-q4-major) 6.3.1 20170620 (release) [ARM/embedded-6-branch
> > > > revision 249437]
> > > >
> > > > The shadow stack is placed on a different RAM chip and is protected
> > > > using software fault isolation (SFI). For SFI i have used a GIMPLE
> > > > pass, but to save the Link Register in the protected memory i had to
> > > > use an RTL pass, because FWIU GIMPLE has no notion of registers. Anyhow i
> > > > am able to generate insn(s) for saving stack pointer to a symbol
> > > > "shadowStack", created by RTL pass (currently
> > > > there is no indexing, wanted to start simple). Here's the insn
> > > > generated for the prologue:
> > > >
> > > > (insn 21 2 20 2 (set (reg/f:SI 110)
> > > >         (symbol_ref:SI ("shadowStack") [flags 0x2])) ./test.c:35 -1
> > > >      (nil))
> > > > (insn 20 21 5 2 (set (mem/c:SI (reg/f:SI 110) [0  S4 A32])
> > > >         (reg:SI 14 lr)) ./test.c:35 -1
> > > >      (nil))
> > > >
> > > > I have tried to copy what cc1 actually generated for an external
> > > > reference. The one thing that is different is that there is no
> > > > information about the variable declaration ins symbol_ref as
> > > > shadowStack is not defined in source and is purely introduced by the
> > > > RTL pass.  My plan is to provide shadowStack using a library (which in
> > > > the end version would be an array). I did something similar for GIMPLE
> > > > pass to call functions in an external library and it worked for me.
> > > > However when i run it i get the following error message:
> > > >
> > > > ./test.c: In function 'iowrite_example':
> > > > ./test.c:40:1: error: insn does not satisfy its constraints:
> > > >  }
> > > >  ^
> > > > (insn 21 2 20 (set (reg/f:SI 110)
> > > >         (symbol_ref:SI ("shadowStack") [flags 0x2])) ./test.c:35 172
> > > > {*arm_movsi_insn}
> > > >      (nil))
> > > > *** WARNING *** there are active plugins, do not report this as a bug
> > > > unless you can reproduce it without enabling any plugins.
> > > > Event                                        | Plugins
> > > > PLUGIN_ATTRIBUTES               | plugin
> > > > PLUGIN_START_UNIT               | plugin
> > > > PLUGIN_ALL_IPA_PASSES_START      | plugin
> > > > ./test.c:40:1: internal compiler error: in extract_constrain_insn, at
> > > > recog.c:2190
> > > > 0xc8ff4c _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
> > > >     /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/rtl-error.c:108
> > > > 0xc8ffac _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
> > > >     /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/rtl-error.c:119
> > > > 0xc3b8e0 extract_constrain_insn(rtx_insn*)
> > > >     /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/recog.c:2190
> > > > 0x104dad2 note_invalid_constants
> > > >     /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/config/arm/arm.c:17555
> > > > 0x104fab3 arm_reorg
> > > >     /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/config/arm/arm.c:18413
> > > > 0xc8a5e6 execute
> > > >     /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/reorg.c:3952
> > > >
> > > > FWIU these instruction generated are accepted by some RTL templates
> > > > but the constraints on operands are not satisfied. I tried to debug
> > > > the constrain_operands function, and is turns out we are trying to
> > > > match constraints for arm_movsi_insn pattern. So the constraints were:
> > > >
> > > > constraints[0]    const char *    0x1a76cf3 "=rk,r,r,r,rk,m"
> > > > constraints[1]    const char *    0x1a76d02 "rk,I,K,j,mi,rk"
> > > >
> > > > My guess was that it should've matched second last alternative but it
> > > > didn't, but i am pretty sure there is nothing wrong with
> > > > constrain_operands, but something is wrong with the way i generated
> > > > the reference. Is there any place i can look for on how to do this
> > > > properly? if required i can share the code here as well for the pass
> > > > (basically i just used gen_rtx_SYMBOL_REF for creating the reference,
> > > > and to be sure there's only one SYMBOL_REF
> > > > (https://gcc.gnu.org/ml/gcc/2003-06/msg02331.html) i save the ref in a
> > > > global variable). Any pointers on what could be wrong in the way i
> > > > generated the reference? Secondly is there any effort going on
> > > > incorporating safe stack with GCC? Lastly please tell me if this
> > > > question belongs here or gcc-help list? i tried gcc-help but it looks
> > > > like most question there are for GCC users not developers.
> > >
> > > You should probably add and assemble the global external variable
> > > early in the compilation.
> > >
> > > > Thanks,
> > > > Arslan

      reply	other threads:[~2019-06-02  5:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-27 23:01 Arslan Khan
2019-05-29  7:17 ` Richard Biener
2019-05-29 21:50   ` Arslan Khan
2019-05-31  8:37     ` Richard Biener
2019-06-02  5:05       ` Arslan Khan [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='CAE2e3sJjZi5Rd_E0a+m=CBoww_3Vduc1LYNymD9-Lg5ztxUMGg@mail.gmail.com' \
    --to=arslankhan52@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /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).