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
