Joey, Thanks for your understanding response and sorry for my late reply. I have been badly caught up in work related stuff, lately.
As you might already be aware of, -mno-PDITR and -mSPB are primarily targeted for MMU-less targets (or where you do have MMU but do not want to/cannot use address translation (virtual address mapping) for other reasons/constraints). Typically these targets are relatively low-end (to mid-range) and both processing power and RAM can be precious resources. On such targets dynamic linking and loading may be a kind of luxury. So instead of full-blown process model/shared object model, simpler dynamic models are more viable. Typically a simple dynamic model, that allows XIP (execute in-place) execution as well, can be implemented with -mno-PDITR only. -mSPB is needed only when you need to control the location of GOT as well. Now moving GOT independent of TEXT section is normally not required as it can be treated as read-only and so be kept with CODE segment (hence at fixed offset to TEXT). Moreover introducing -mSPB comes at a performance cost and considerable complexity on part of the OS runtime that implements such a dynamic model (as you need to introduce traps and call stubs/trampoline layers to transparently switch the GOT on inter-object call boundaries). So the typical usage of these flags is -mno-PDITR alone. On the other hand, when -mSPB is used, -mno-PDITR would typically also be used, because otherwise your local-scope i.e. static globals would not be placed correctly as compiler normally does not route them through GOT without -mno-PDITR. So -mSPB without -mno-PDITR is usable only if your dynamic objects have no static globals. In short, -mno-PDITR alone is highly useful and should not imply -mSPB. However, if we do want to do something, -mSPB can be made to imply -mno-PDITR as this is the typical usage for -mSPB. So Nathan's patch should have been the other way around: -mSPB should imply -mno-PDITR rather than -mno-PDITR implying -mSPB. Thanks, Irfan Ahmad On Fri, Aug 5, 2016 at 2:12 PM, Joey Ye <joey...@foss.arm.com> wrote: > 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 > >
