public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tjvries at xs4all dot nl" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/31230] debug information depends on gc parameters Date: Mon, 21 Jun 2010 10:32:00 -0000 [thread overview] Message-ID: <20100621103205.14785.qmail@sourceware.org> (raw) In-Reply-To: <bug-31230-230@http.gcc.gnu.org/bugzilla/> ------- Comment #5 from tjvries at xs4all dot nl 2010-06-21 10:32 ------- Created an attachment (id=20954) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20954&action=view) naive patch. run callbacks on hashtable entries exhaustively before deleting Furthermore, I investigated why this problem does not occur with 4.4.0 onwards, and I found that this is due to the fact that -funit-at-a-time is hard coded to on for 4.4.0, which causes f1 to be live at the same time as f3 (no cgraph_release_function_body() in between). An easy workaround for this problem in 4.3.5 is therefore -funit-at-a-time. I also managed to reproduce the problem for -gstabs. The patch from comment 3 works indeed, but not for -gstabs, which makes a lot of sense since the patch is dwarf specific. Of course we might attempt to fix the stab format (and possible others) in a similar way, but the fact that the fix needs to be repeated made me wonder whether the problem had to be dealt with at another level than specific debug formats. Let's take a look at what happens exactly during garbage collection in between f1 and f3 in mark_roots(): - gt_ggc_rtab is traversed, and neither array type nor index type is marked live - gt_ggc_cache_rtab is traversed, in particular type_hash_table, and the hash entry with the index type is hit (before the entry with the array type, but this is non-deterministic) and processed by ggc_htab_delete(). The entry is not considered live, and consequently the entry is cleared. - next the entry with the array type is hit and processed by ggc_htab_delete(). The entry is considered live due to TYPE_SYMTAB_POINTER (type). Consequently the callback is called, marking the entry and everything reachable from it live, including the index type. Unfortunately, the hash entry for the index type is already gone. During parsing of f3, a new index type equivalent to the old one is created, but type_hash_canon cannot find the old index type in the hash table (since that entry has been deleted), so the new index type is now a canonical type, and gets an entry in the type_hash_table. Next, a new array type equivalent to the old one is created, but type_hash_canon cannot find the old array type, even though the entry has not been deleted. The new array type has a different index type than the old array type, and consequently the hashcode for the new array type is different than the hascode for the old array type, so the old array type is not found. The new array type is now also a canonical type, and gets an entry in the type_hash_table. The old index type, the old array type and the hash table entry associated with the old array type are now unused but not freed. The question is whether to blame this on - invalid use of the garbage collection infrastructure. Using the if_marked construction to mark an object live, is only allowed if everything reachable from that object is also live. - the garbage collection infrastructure itself. If the if_marked construction is used to mark an object live, the garbage collection infrastructure should mark everything that is reachable from that object also as live. The patch in comment 3 seems to take the first choice. I decided to explore the second choice, and created a naive patch of ggc_mark_roots(). It solves the inconsistent debug info problem, both for dwarf2 and for stabs. I did a debug bootstrap build (-g3 -O0 -dH) with the patch and ran the testsuites (gcc, objc, gfortran, g++, libgomp, libstdc++, libjava, libmudflap, libffi), with the same results as a normal bootstrap build without the patch, so the patch looks sane at least. This is my first time looking into the gcc garbage collector, so I'd appreciate some comments on my findings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230
next prev parent reply other threads:[~2010-06-21 10:32 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-03-16 20:25 [Bug debug/31230] New: " jsm28 at gcc dot gnu dot org 2007-03-16 20:26 ` [Bug debug/31230] " jsm28 at gcc dot gnu dot org 2007-03-30 21:44 ` wilson at gcc dot gnu dot org 2007-03-30 21:49 ` wilson at gcc dot gnu dot org 2010-06-21 10:20 ` tjvries at xs4all dot nl 2010-06-21 10:32 ` tjvries at xs4all dot nl [this message] [not found] <bug-31230-4@http.gcc.gnu.org/bugzilla/> 2022-12-01 1:42 ` pinskia at gcc dot gnu.org
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=20100621103205.14785.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /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: linkBe 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).