This is the mail archive of the gcc-patches@gcc.gnu.org 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]

Re: DWARF2 PATCH: Another debugging/inlining problem


>This is a patch for PR1645.  Again, I would appreciate any comments
>from people with particular expertise.

PR1645 is a fortran optimization problem.  It doesn't appear to be the
problem you are looking at.

>Then loc_descriptor_from_tree calls eliminate_regs -- but nobody has
>called init_elim_table yet so we crash.

It isn't clear how you got to loc_descriptor_from_tree.

Your general premise that DECL_ABSTRACT values should not have location
descriptors is correct.  This is why gen_formal_parameter_die does this
      if (! DECL_ABSTRACT (node))
        add_location_or_const_value_attribute (parm_die, node);

We must have gotten there some other way.  I think the only other way we
can get there is when emitting the type of the parameter if it is a dynamic
array type.  In that case, emitting debug info for the type requires references
to other parameters, which requires location descriptors for those other
parameters, which we can't do in an abstract instance.

That leads to the next question which is what the debug info looks like in
the concrete instances.  If they just refer to the type in the abstract
instance, which is what I would expect, and the abstract instance has
incomplete type info, then we lose.

I think to solve this correctly, we need to rethink how we emit debug info
for dynamic sized types in abstract instances.

Your patch just hides the problem, by emitting incomplete debug info to
avoid the abort.  This is OK on the gcc-3 release branch, but I wouldn't
put such a patch on the trunk.  If we leave the trunk broken, then we still
have a chance to fix it correctly.  If we hide the problem on the trunk, then
we may not notice it is broken for a long time again.  If we do need to
hide the problem on the trunk, we should at least put in a ??? comment,
or make it abort when enable checking is turned on, or do something else to
make it clear that we have a bug that still needs to be fixed.

For efficiency reasons, you might want to put the DECL_ABSTRACT check higher
up in the call chain.  If my analysis is right, then putting it in
add_bound_info before the loc_descriptor_from_tree call should work.
I think you can check current_function_decl for the DECL_ABSTRACT flag.
You could then put a meaningful ??? comment there to describe the breakage.

Jim


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