On 12/07/16 13:02, Nathan Sidwell wrote: > Ramana, > could you review this?
Sorry missed this. > > original thread https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00630.html, > reproduced below: > > > currently, the documentation for -mno-pic-data-is-text-relative (-mno-PDITR) > says > 'Assume that each data segments are relative to text segment at load time. > Therefore, it permits addressing data using PC-relative operations. > This option is on by default for targets other than VxWorks RTP.' > > However, if you use just this option, you still end up with a pic-register > init sequence that presumes a fixed mapping. That's a surprise. Joey tells me > its expected use is with -msingle-pic-base (-mSPB), which reserves a global > register to point at the (single) GOT. That's what I had expected the > -mno-PDITR option to have implied. > > Apparently there are legitimate reasons one might want the -mno-PDITR > behaviour without -mSPB. I don't know what those are though. > > Anyway, IMHO that is the rare case and the more common case is that one would > want to have -mnoPDITR imply -mSPB. (The reverse probably doesn't apply.) > > This patch does 3 things. > 1) have -mno-PDITR imply -mSPB, unless one has explicitly provided -m[no-]SPB. > 2) clarified the -m[no-]PDITR documentation. > 3) Added some testcases -- there didn't appear to be any. > > ok? > Ok and thank you for the testcases. -mno-PDITR => -mSPB by default (in the absence of -mno-SPB on the command line) seems correct after having done the necessary archeology. 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. Thanks, Ramana > nathan
