public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Marek Polacek <polacek@redhat.com>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
	       Chen Gang <gang.chen.5i5j@gmail.com>,
	rth@redhat.com,        gcc-patches@gcc.gnu.org, davem@redhat.com,
	Jeff Law <law@redhat.com>,
	       Guenter Roeck <linux@roeck-us.net>,
	       "Bin.Cheng" <amker.cheng@gmail.com>
Subject: Re: [PATCH] gcc/c/c-decl.c: Let NEWDECL dereference shared data to fix segment fault issue.
Date: Sun, 29 Jun 2014 20:59:00 -0000	[thread overview]
Message-ID: <20140629205939.GB29278@redhat.com> (raw)
In-Reply-To: <20140629200034.GB22855@kam.mff.cuni.cz>

On Sun, Jun 29, 2014 at 10:00:34PM +0200, Jan Hubicka wrote:
> > On Sun, 29 Jun 2014, Chen Gang wrote:
> > 
> > > NEWDECL dereferences shared data of OLDDECL, or when free NEWDECL, also
> > > have effect with OLDDECL. At present, only fix the related reference for
> > > current issue. If find another related issue, can follow this fix.
> > 
> > I'm afraid I can't make any sense of this.
> > 
> > We need a carefully written analysis of the issue you are trying to fix 
> > that explains what is going wrong and why, in terms of the underlying 
> > design of the code, the proposed change is logically correct to fix the 
> > issue.
> > 
> > That is, explain how NEWDECL gets used after merge_decls returns, why your 
> > proposed changes to NEWDECL are correct for the subsequent use of NEWDECL, 
> > why the previous contents of NEWDECL would be incorrect for the subsequent 
> > uses of NEWDECL, and why it is correct for the subsequent uses to make 
> > whatever use of NEWDECL is causing problems.  Where does the segfault 
> > occur anyway?
> 
> Actually this problem was introduced by me (and I made patch for it once already
> but apparently it did not reach the ML). THe problem is that we now create symbols
> to hold information about decl that is no longer represented in trees - sections,
> comdats etc.
> 
> Now in duplicate_decl we have two symbol nodes for the duplicated declarations
> and remove one of them at the end.  cgraph_remove_node calls
> cgraph_release_function_body that assumes that we never have two functions with
> same DECL_STRUCT_FUNCTION.
> 
> So Cheng is right we need to clear DECL_STRUCT_FUNCTION or we end up ggc_freeing
> it that later ICEs in push_cfun.  We do not need to clear the other fields.
> 
> The patch bellow just copy identical hunk of code from cp/decl.c
> > 
> > >   root@gchen:/upstream/linux# cat elevator.i
> > >   extern int __attribute__ ((__section__(".init.text"))) elv_register(void)
> > >   {
> > >    return 0;
> > >   }
> > >   extern typeof(elv_register) elv_register;
> > 
> > Patch submissions should add a test to the testsuite, when it's something 
> > small like this.
> 
> Added.
> 
> thanks for working on this!  I am bootstrapping/regtesting the attacked patch on x86_64-linux
> OK?

Just some typos:

> 	Chen Gang <gang.chen.5i5j@gmail.com>

Two spaces after the name.

> 	Jan Hubicka  <hubicka@ucw.cz>
> 
> 	* c-decl.c (duplicate_decls): CLear DECL_STRUCT_FUNCTION before releasing
> 	symbol.

s/CLear/Clear/

> Index: c/c-decl.c
> ===================================================================
> --- c/c-decl.c	(revision 212098)
> +++ c/c-decl.c	(working copy)
> @@ -2575,7 +2575,14 @@ duplicate_decls (tree newdecl, tree oldd
>  
>    merge_decls (newdecl, olddecl, newtype, oldtype);
>  
> -  /* The NEWDECL will no longer be needed.  */
> +  /* The NEWDECL will no longer be needed.
> +
> +     Before releasing the node, be sore to remove function from symbol

s/sore/sure/

> +     table that might have been inserted there to record comdat group.
> +     Be sure to however do not free DECL_STRUCT_FUNCTION becuase this

s/becuase/because/

> +     structure is shared in between newdecl and oldecl.  */

s/newdecl/NEWDECL/;s/oldecl/OLDDECL/

	Marek

  reply	other threads:[~2014-06-29 20:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-29 12:52 Chen Gang
2014-06-29 13:30 ` Joseph S. Myers
2014-06-29 20:00   ` Jan Hubicka
2014-06-29 20:59     ` Marek Polacek [this message]
2014-06-29 21:24     ` Joseph S. Myers
2014-06-30  1:26       ` Chen Gang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140629205939.GB29278@redhat.com \
    --to=polacek@redhat.com \
    --cc=amker.cheng@gmail.com \
    --cc=davem@redhat.com \
    --cc=gang.chen.5i5j@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=joseph@codesourcery.com \
    --cc=law@redhat.com \
    --cc=linux@roeck-us.net \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).