[ARM] mno-pic-data-is-text-relative & msingle-pic-base

Joey Ye joey.ye@foss.arm.com
Fri Aug 5 09:12:00 GMT 2016


Thanks for the case sharing. It is a persuasive reason not to error out -mno-SPB. 

Nathan's patch changes default behaviour that -mSPB will be implied when -mno-PDITR is provided. So with this patch your project need to explicitly specify -mno-SPB to make it work as before. IMHO default behaviour should reflect the typical usage. Now I not so sure whether -mSPB should be typically used with -mno-PDITR. Irfan what's your opinion?


> -----Original Message-----
> From: Irfan Ahmad [mailto:h.irfanahmad@gmail.com]
> Sent: 05 August 2016 07:06
> To: Ramana Radhakrishnan; Nathan Sidwell; Joey Ye; GCC Patches
> Cc: Richard Earnshaw
> Subject: Re: [ARM] mno-pic-data-is-text-relative & msingle-pic-base
> Ramana,
> I saw some correspondence between you and Nathan on his patch
> [https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00630.html] (after I sent this
> email) going in a direction that may eventually result in too tight than necessary
> coupling between these two switches, as your response hints at:
> > I am also slightly inclined to go further and error out if someone uses -mno-
> PDITR with -mno-SPB on the command line, after all as you say -mno-PDITR
> implies a non-fixed mapping while -mno-SPB implies there is some fixed mapping
> some where currently in the compiler. I don't see how the twain can meet. That
> can happen as a follow-up - the current patch is by itself a step improvement.
> Please see the alternative perspective as described below.
> Irfan Ahmad
> [p.s. Sorry about repeat send. I accidentally sent it earlier in HTML format]
> --------------------------------------------------------------------------------------------------
> ---------
> On 05/08/2016 09:56, Irfan Ahmad wrote:
> Nathan,
> Sorry for jumping in a relatively old thread. I saw this in mailing list archives
> during a web search (I wasn't on this mailing list before). I decided to speak up as
> I would be an affected party if this patch (or some similar future patch) gets
> accepted or worse yet, the feature involved gets disabled.
> > Apparently there are legitimate reasons one might want the -mno-PDITR
> behaviour without -mSPB. I don't know what those are, perhaps Joey could
> clarify?
> Yes, there are some practical use cases that require -mno-pic-data-is-text-
> relative (-mno-PDITR) without -msingle-pic-base (-mSPB).
> These are based on two primary principles:
> 1. In the absence of lazy binding (that is almost always the case in embedded
> systems), GOT is practically read-only - it needs to be modified only during
> linking by the dynamic linker, after that it can be considered and marked read-
> only (e.g. read-only attribute set to be enforced by some MMU or MPU).
> 2. If you only need a simple dynamic object model - where you just need
> dynamic loading and dynamic linking - but do not need to maintain multiple data
> states for the object like you need in a traditional shared object model, then one
> instance of GOT per dynamic object is enough.
> From #1: GOT is read-only so keeping it with CODE segment is a natural choice.
> Now as there is no need to move it to RAM so there is no need for a mechanism
> (-mSPB) that would enable controlling the GOT location independently of CODE
> segment.
> From #2: Only one instance of GOT is required per dynamic object so there is no
> need for a mechanism (-mSPB) that would enable switching GOTs.
> So when both #1 and #2 are met, you only need -mno-pic-data-is-text-relative.
> Irfan Ahmad

More information about the Gcc-patches mailing list