Irfan, 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? Thanks, Joey > -----Original Message----- > From: Irfan Ahmad [mailto:h.irfanah...@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
