This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH]: Fix debug/17924 and debug/19191, take two
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: gcc-patches at gcc dot gnu dot org
- Date: Sun, 2 Jan 2005 15:10:43 -0500 (EST)
- Subject: [PATCH]: Fix debug/17924 and debug/19191, take two
This is an updated patch to fix debug/17924 and debug/19191, both 4.0
regressions (17924 is the dwarf-die7.c testsuite failure).
It required fixing a few latent bugs in the process.
The main problem that caused the original failures in dwarf-die7.c and the
testcase from 19191 is that when we rearranged the block tree, this threw
the block used flags out of whack with respect to what we expected them to
be.
The debug outputters expect that the blocks are marked used if any of
their subblocks are used (or in the case of dwarf-die7, if the abstract
origin is used, in case the inlined function has no local variables or
parameters to cause it to be marked used).
I've added a pass that just walks the function block tree and makes the
used flags "correct". Hopefully we can revisit how our debug info output
is driven for 4.1 so that things like this aren't necessary, but that type
of change seemed a bit invasive for 4.0. It's also not always smart
enough to elide unused debug info when we just have it walk all the blocks
(IE ignore the used flag), so doing that may have caused a debug info size
regression with respect to 3.4 for info that wasn't actually used. So I
chose to just put that type of change off for 4.1.
The two latent bugs this patch exposed (the same latent bugs are exposed
by just having the debug info writer ignore the used flag, so even if
someone told me to take that approach, these have to be fixed anyway) are
as follows:
1. We wouldn't follow the decl's origin given as a block's
abstract origin in block_ultimate_origin.
This would lead to the problem that we would have a block like so:
inlined block foo with an abstract origin of
decl comp_ctor with an abstract origin of
decl bad_typeid
We'd return comp_ctor's decl as the block_ultimate_origin, which is wrong,
and would later cause us to try to add it as the abstract origin, and fail
miserably (because we'd actually output the bad_typeid decl because it's
the decl_ultimate_origin of comp_ctor).
More detail about this problem can be found in the audit trail of 17924.
2. cgraph_remove_node sometimes blows away the tree blocks for a node
when expand_call_inline calls cgraph_remove_node, because the node is now
completely dead. However, in certain cases, if it was inlined, and it
had blocks in it that were used by the inlined things as the abstract
origin, we'd abort because we'd no longer have those blocks available
when we later called dwarf2out_abstract_function, making them never get
output, and making things like gen_variable_die fail + abort when
they tried to add the correct abstract origin of an inlined variable.
This is fixed by simply calling the outlining_inline_function debug
hook when we've known to have inlined a function, in expand_call_inline.
This makes sure the debug info for the function is output (even if the
function later disappears) so that it can be used as the abstract origin
of the inlined subroutines/variables. Again, i'd like to try to revisit
how we drive debug info output a bit so that all of this stuff isn't so
circular and nasty to try to debug. I don't know if that's possible.
Note that this only causes it to output debug info when the function has
actually been inlined, not if it "may" be inlined (otherwise, we'd fail
dwarf-die1.c)
Bootstrapped and regtested on i686-pc-linux-gnu.
Okay for mainline?
(The attached testcase is for one of the latent bugs and will be added
as dwarf2 testcases to g++.dg/debug/dwarf2, just as soon as i make
sure that dir is working right. I will do it before i commit this patch,
if approved)Attachment:
17924.diff
Description: Text document
Attachment:
dwarf-die1.cc
Description: Text document