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]

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.

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