public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Joey Ye" <joey.ye@arm.com>
To: "Richard Earnshaw" <Richard.Earnshaw@arm.com>
Cc: <gcc-patches@gcc.gnu.org>
Subject: RE: [patch] [arm] New option for PIC offset unfixed
Date: Wed, 13 Nov 2013 11:16:00 -0000	[thread overview]
Message-ID: <000001cee05a$0b8dbd80$22a93880$@arm.com> (raw)
In-Reply-To: <52834B21.5080305@arm.com>

> -----Original Message-----
> From: Richard Earnshaw
> Sent: Wednesday, November 13, 2013 17:49
> To: Joey Ye
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [patch] [arm] New option for PIC offset unfixed
> 
> On 13/11/13 06:18, Joey Ye wrote:
> >> -----Original Message-----
> >> From: Richard Earnshaw
> >> Sent: Tuesday, November 12, 2013 18:49
> >> To: Joey Ye
> >> Cc: gcc-patches@gcc.gnu.org
> >> Subject: Re: [patch] [arm] New option for PIC offset unfixed
> >>
> >> The name of the option and the documentation highlights that the
> >> option's concept is confusing.
> >>
> >> I think what you really need to do is to reverse the sense of the
> >> option name and have
> >>
> >> -mpic-data-is-text-relative
> >>
> >> with the inverse (-mno-pic-data-is-text-relative) being the active
> >> value that triggers for vxworks.  That is, PIC data being
> >> text-relative is the default for all targets except vxworks.
> >>
> >> R.
> >>
> >> Oh, and at run time, we should be talking about segments, not sections!
> > Richard, Thanks for quick response.
> >
> > Updated patch renamed the option, variables and macro. Also use
> > segments in document. OK?
> >
> > 2013-11-13  Joey Ye  <joey.ye@arm.com>
> >
> > 	* config/arm/arm.c (arm_option_override):  Error if
> > 	-mpic-data-is-text-relative without -fpic, and set for
> > 	VxWorks RTP.
> > 	(legitimize_pic_address): Use arm_pic_data_is_text_relative
> > 	(arm_assemble_integer): Likewise.
> > 	* config/arm/arm.h
> > 	(TARGET_DEFAULT_PIC_DATA_IS_TEXT_RELATIVE): New macro.
> > 	* config/arm/arm.opt (mpic-data-is-text-relative): New option.
> > 	* doc/invoke.texi (-mpic-data-is-text-relative): Doc for new option.
> >
> >
> > pic_data_text_rel-1113.patch.txt
> >
> >
> > diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index
> > 7757e86..fdd5684 100644
> > --- a/gcc/config/arm/arm.c
> > +++ b/gcc/config/arm/arm.c
> > @@ -2504,6 +2504,13 @@ arm_option_override (void)
> >  	arm_pic_register = pic_register;
> >      }
> >
> > +  if (TARGET_VXWORKS_RTP)
> > +    arm_pic_data_is_text_relative = 0;
> 
> Why is this needed?  Surely, even a VxWorks user should have the right to
> force the compiler to behave differently.  You've set things up through
the
> default, now just accept what the user has asked for.
The reason is that TARGET_VXWORKS_RTP isn't a compile time value to initiate
arm.opt. Instead it is true only when -mrtp is specified in runtime. Also
enable text relative may result in runtime error on vxworks, it is better to
prevent it here.
> 
> 
> > +
> > +  if (arm_pic_data_is_text_relative !=
> TARGET_DEFAULT_PIC_DATA_IS_TEXT_RELATIVE
> > +      && !flag_pic)
> > +    error ("-mpic-data-is-text-relative must be used with -fpic");
> 
> I'm not sure about this either.  The option should just be ignored when
not
> PIC.
It is ignored if -fpic isn't given. I'm OK to remove the error here, while
Ramana preferred to error it.

> 
> > +
> >    /* Enable -mfix-cortex-m3-ldrd by default for Cortex-M3 cores.  */
> >    if (fix_cm3_ldrd == 2)
> >      {
> > @@ -6020,7 +6027,7 @@ legitimize_pic_address (rtx orig, enum
> machine_mode mode, rtx reg)
> >  	   || (GET_CODE (orig) == SYMBOL_REF &&
> >  	       SYMBOL_REF_LOCAL_P (orig)))
> >  	  && NEED_GOT_RELOC
> > -	  && !TARGET_VXWORKS_RTP)
> > +	  && arm_pic_data_is_text_relative)
> >  	insn = arm_pic_static_addr (orig, reg);
> >        else
> >  	{
> > @@ -21498,7 +21505,7 @@ arm_assemble_integer (rtx x, unsigned int size,
> int aligned_p)
> >  	{
> >  	  /* See legitimize_pic_address for an explanation of the
> >  	     TARGET_VXWORKS_RTP check.  */
> > -	  if (TARGET_VXWORKS_RTP
> > +	  if (!arm_pic_data_is_text_relative
> >  	      || (GET_CODE (x) == SYMBOL_REF && !SYMBOL_REF_LOCAL_P
> (x)))
> >  	    fputs ("(GOT)", asm_out_file);
> >  	  else
> > diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h index
> > 1781b75..dbd841e 100644
> > --- a/gcc/config/arm/arm.h
> > +++ b/gcc/config/arm/arm.h
> > @@ -568,6 +568,10 @@ extern int prefer_neon_for_64bits;
> >  #define NEED_PLT_RELOC	0
> >  #endif
> >
> > +#ifndef TARGET_DEFAULT_PIC_DATA_IS_TEXT_RELATIVE
> > +#define TARGET_DEFAULT_PIC_DATA_IS_TEXT_RELATIVE 1 #endif
> > +
> >  /* Nonzero if we need to refer to the GOT with a PC-relative
> >     offset.  In other words, generate
> >
> > diff --git a/gcc/config/arm/arm.opt b/gcc/config/arm/arm.opt index
> > 9b74038..fa0839a 100644
> > --- a/gcc/config/arm/arm.opt
> > +++ b/gcc/config/arm/arm.opt
> > @@ -158,6 +158,10 @@ mlong-calls
> >  Target Report Mask(LONG_CALLS)
> >  Generate call insns as indirect calls, if necessary
> >
> > +mpic-data-is-text-relative
> > +Target Report Var(arm_pic_data_is_text_relative)
> > +Init(TARGET_DEFAULT_PIC_DATA_IS_TEXT_RELATIVE)
> > +Assume data segments are relative to text segment.
>                            ^
> Assume data segment will be loaded at a fixed relative offset to the text
> segment.
Accepted
> 
> > +
> >  mpic-register=
> >  Target RejectNegative Joined Var(arm_pic_register_string)  Specify
> > the register to be used for PIC addressing diff --git
> > a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 863e518..298fcc3
> > 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -12120,6 +12120,12 @@ before execution begins.
> >  Specify the register to be used for PIC addressing.  The default is
> > R10  unless stack-checking is enabled, when R9 is used.
> >
> > +@item -mpic-data-is-text-relative
> > +@opindex mpic-data-is-text-relative
> > +Assume that each data segments are relative to text segment at load
time.
> 
> > +Therefore, prevent PC relative and GOTOFF style relocations to
> > +reference data.
> 
> I think the sense of this sentence is now backwards.  I'd also try to
avoid
> GOTOFF in the user part of the manual.
How about
"Therefore, prevent addressing data with relocation types that doesn't apply
in such circumstance."

> 
> > This is on by default for targets other than VxWorks RTP.
> > +
> >  @item -mpoke-function-name
> >  @opindex mpoke-function-name
> >  Write the name of each function into the text section, directly
> >
> 
> R.



  reply	other threads:[~2013-11-13 10:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12 10:12 Joey Ye
2013-11-12 13:37 ` Richard Earnshaw
2013-11-13  9:06   ` Joey Ye
2013-11-13 10:52     ` Richard Earnshaw
2013-11-13 11:16       ` Joey Ye [this message]
2013-11-13 11:46         ` Richard Earnshaw
2013-11-13 17:23           ` Joey Ye
2013-11-13 12:21         ` Richard Earnshaw
     [not found]           ` <45520D6299C11E4588128526465332BB3BDBAD147A@SAROVARA.Asiapac.Arm.com>
2013-11-13 18:00             ` Richard Earnshaw
2013-11-14 10:09 Joey Ye
2013-11-14 10:48 ` Richard Earnshaw
2013-11-14 12:53   ` Joey Ye

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='000001cee05a$0b8dbd80$22a93880$@arm.com' \
    --to=joey.ye@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).