This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR debug/19345
On Thu, 27 Jan 2005, Daniel Berlin wrote:
On Thu, 27 Jan 2005, Daniel Berlin wrote:
On Wed, 26 Jan 2005, Mark Mitchell wrote:
Daniel Berlin wrote:
Rather than add a null check in decl_function_context, i've simply
guarded against calling it here with null (we already were assuming it
could return null, so what's 2 null checks when you've already got 1
:P).
Everything else DTRT once we exit our if block.
Bootstrapped and regtested on i686-pc-linux-gnu. Okay for mainline?
That doesn't seem right to me, as this type is indeed local to a
function. I'd say that DECL_CONTEXT applied to the type should indeed be
a FUNCTION_DECL.
Since we seem to have had a miscommunication as to what this function
does and what is going wrong, let me just clearly state what is going on,
and you can tell me where you think the bug is.
add_abstract_origin_attribute is used to say that "this thing over here
isn't the real definition of that thing. It really came from this origin
over here, and we are just an inlined use of it".
gen_inlined_structure_type_die is used to say "we are an inlined
instance of this structure type". In the process of saying that, it calls
add_abstract_origin_attribute to tell us where it really came from.
When add_abstract_origin_attribute gets passed a type as the
presumed origin by gen_inlined_structure_type_die, there are two
possibilities currently:
1. The origin type is a "real" type die. IE the type in
question really came from itself. It was completely local to the
function, or whatever.
2. The origin type is not local to this function, and we want to find
the stub so we can make sure everything necessary for its context was
output before adding our origin.
Note the current code is not working always in the first case.
This is not necessarily surprising. The code in question was built to
handle the second case, and to make sure that the context for the
non-local type was set up properly, so that the debug info looks right.
My patch purports to fix the code in the first case, assuming it's
currently broken (because it doesn't work :P).
In the first case, for our testcase, where the origin type is a real type,
there is no TYPE_STUB_DECL right now for the type declared in the asm.
Are all types supposed to have a TYPE_STUB_DECL, regardless of where they
were created?
If so, then i also believe this bug is somewhere in the frontends, not
creating a TYPE_STUB_DECL for the type "created" in the asm.
If not, then i believe the bug is what the patch fixed: That, if not all
type's have a TYPE_STUB_DECL, then we need to be prepared to handle this
case, and do something sensible.