This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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

Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]