[PATCH] D101156: [Clang] Support a user-defined __dso_handle

Andrew Savonichev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed May 12 14:14:39 PDT 2021


asavonic added a comment.

In D101156#2724789 <https://reviews.llvm.org/D101156#2724789>, @rjmccall wrote:

> What's the crash exactly/  Is IRGen just unhappy about processing the user definition when we've generated a declaration with a different type?  Because we're already supposed to be being cautious about this.

Hi John. Sorry for the late reply.

  class a {
  public:
    ~a();
  } b;
  void *__dso_handle = &__dso_handle;

This code code causes a crash because the compiler first generates a
__dso_handle with i8 type:

  @__dso_handle = external dso_local global i8

... and then reaches the explicit definition of it with a pointer type and a
pointer initializer, and tries to generate this instead:

  @__dso_handle = hidden global i8* bitcast (i8** @__dso_handle to i8*), align 8

Since __dso_handle already exists in the module, it must be replaced because the
initializer has an incompatible type.

There is indeed some handling for this case in EmitGlobalVarDefinition, but it
does not work correctly when the initializer is a pointer to the variable
itself. Specifically, the Init variable in EmitGlobalVarDefinition becomes
stale:

  p Init->dump()
  <badref> = hidden global i8 <null operand!>

The current patch avoids this problem by having two distinct globals, but maybe
it is better to fix EmitGlobalVarDefinition instead? Is it supposed to handle
such case?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101156/new/

https://reviews.llvm.org/D101156



More information about the cfe-commits mailing list