[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

hjl.tools at gmail dot com gcc-bugzilla@gcc.gnu.org
Thu Apr 16 11:46:00 GMT 2015


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780

--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to H.J. Lu from comment #9)
> > Created attachment 35327 [details]
> > A different patch
> > 
> > On x86, this issue only shows up with PIE. Here is a different
> > patch to treat common symbol defined locally only if the backend
> > passes true common_maybe_local.  For x86-64, it is true only if
> > HAVE_LD_PIE_COPYRELOC is 1.  For i386, it is always false.  If
> > we aren't building PIE, common_maybe_local is true or false
> > doesn't make a difference for x86 since the common symbol is
> > always referenced normally with copy reloc.  For PIE on x86-64,
> > common symbol is local only if HAVE_LD_PIE_COPYRELOC is 1.
> 
> +
> +  /* For common symbol, it is defined locally only if common_maybe_local
> +     is true.  */
> +  bool defined_locally = (!DECL_EXTERNAL (exp)
> +			  && (!DECL_COMMON (exp) || common_maybe_local));
> 
> I think better would be:
>   bool uninited_common = (DECL_COMMON (exp)
>                           && (DECL_INITIAL (exp) == NULL
>                               || (!in_lto_p && DECL_INITIAL (exp) ==
> error_mark_node)));
>   /* For common symbol, it is defined locally only if common_maybe_local
>      is true.  */
>   bool defined_locally = (!DECL_EXTERNAL (exp) && (!uninited_common ||
> common_maybe_local));
> ...
> and then use
>   /* Uninitialized COMMON variable may be unified with symbols
>      resolved from other modules.  */
>   if (uninited_common && !resolved_locally)
>     return false;

Here is a testcase:

---
int optopt = 5;
int optopt;

int
main ()
{
  optopt = 4;
  return 0;
}
----
~


More information about the Gcc-bugs mailing list