This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Add diagnostics when initialization global variables with ropi/rwpi
Needs ReviewPublic

Authored by efriedma on Jan 10 2017, 12:09 PM.

Details

Summary

This patch adds diagnoses when initializing a global variable using the address of another global variable that uses ROPI/RWPI relocation model.

For example,
int a;
extern void foo();
int *x = &a; we cannot statically initialize x with -frwpi
void *y = &foo();
we can't statically initialize y with -fropi

Diff Detail

Event Timeline

weimingz updated this revision to Diff 83844.Jan 10 2017, 12:09 PM
weimingz retitled this revision from to [ARM] Add diagnostics when initialization global variables with ropi/rwpi.
weimingz updated this object.
weimingz added reviewers: olista01, jmolloy.
weimingz added a subscriber: cfe-commits.
efriedma requested changes to this revision.Jan 10 2017, 12:55 PM
efriedma added a reviewer: efriedma.
efriedma added a subscriber: efriedma.

We really should be checking this much earlier.

IsGlobalLValue() in ExprConstant.cpp is the canonical place to answer the question "is the address of the given expression constant". Getting this right in semantic analysis means you don't have to chase down all the various places which generate global initializers. In addition to global variables, static local variables and compound literals can have static storage duration in C. And sometimes you can even run into trouble with globals which don't exist in the source code. One interesting example:

int a;
int g(const int**);
int f(void) {
  const int *x[] = {&a,&a,&a,&a,&a,&a,&a,&a};
  return g(x);
}

This is valid code whether or not we're in rwpi mode, but clang currently generates IR which won't link in rwpi mode. If semantic analysis concludes that &a isn't a constant, the correct code generation falls out naturally; otherwise, you have yet another place to add an explicit check in IR generation. And I won't even try to go into all the additional corner cases you can run into with C++ code.

As a bonus, you can generate nicer error messages in Sema.

This revision now requires changes to proceed.Jan 10 2017, 12:55 PM

Hi Eli,
Thanks for the comments!
I though of implementation in Sema and I actually experimented a little bit. Then it seemed that the CodeGenOpts is only available in the CGM. Any ideas?

If there isn't already a LangOptions flag which reflects this, it probably makes sense to add one.

weimingz updated this revision to Diff 85446.Jan 23 2017, 12:38 PM
weimingz edited edge metadata.
weimingz edited the summary of this revision. (Show Details)

As Eli sugguested, it's better to check it in Sema. In order to access RelocationModel in Sema, we moved it from CodeGenOpts to LangOpts

efriedma commandeered this revision.Apr 2 2018, 1:30 PM
efriedma edited reviewers, added: weimingz; removed: efriedma.