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
next prev parent 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).