Re: DWARF2 PATCH: Another debugging/inlining problem

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

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

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

Oops.  I was looking at PR1645 too -- but the one I wrote about was
PR2031.

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

    Jim> It isn't clear how you got to loc_descriptor_from_tree.

    Jim> We must have gotten there some other way.  I think the only
    Jim> other way we can get there is when emitting the type of the
    Jim> parameter if it is a dynamic array type.  

Yes.  The stack trace (cut from the PR, but this is what I say in the
debugger too) looks like:

  #0 eliminate_regs (x=0x104af8a0, mem_mode=VOIDmode, insn=0x0)
  #1 0x10249d44 in rtl_for_decl_location (decl=0x0) at dwarf2out.c:8836
  #2 0x10247e0c in loc_descriptor_from_tree (loc=0x104a5b38, addressp=0)
  #3 0x10247f8c in loc_descriptor_from_tree (loc=0x10499cc8, addressp=0)
  #4 0x1024a7ac in add_bound_info (subrange_die=0x104e97c0, 
  bound_attr=DW_AT_upper_bound, bound=0x10499cc8) at dwarf2out.c:9066
  #5 0x1024b3e0 in add_subscript_info (type_die=0x104e4fc8, type=0x0)
  #6 0x1024c2ec in gen_array_type_die (type=0x104a5ee0, context_die=0x104e98e0)

We're generating the information for a PARM_DECL.

    Jim> In that case,
    Jim> emitting debug info for the type requires references to other
    Jim> parameters, which requires location descriptors for those
    Jim> other parameters, which we can't do in an abstract instance.

Does that mean that, with my patch, we will emit ill-formed DWARF2 --
or just incomplete DWARF2?  In other words, can we expect debuggers to
not fall over with my patch, or are they likely to die?  If the
former, it should be OK for 3.0; if the latter, then we need a better
solution.

    Jim> That leads to the next question which is what the debug info
    Jim> looks like in the concrete instances.

I don't know.

    Jim> Your patch just hides the problem, by emitting incomplete
    Jim> debug info to avoid the abort.  This is OK on the gcc-3
    Jim> release branch, but I wouldn't put such a patch on the trunk.

This is that same debate again. :-)

What we really need here is a policy decision by the Steering
Committee, so that we can all avoid trotting out our own points of
view every time.  I will bring up the issue there, since we have
beaten this death, without achieving consensus, on these lists.

In any case, it sounds like you are saying that there should be an
assertion in rtl_for_decl_location indicating that the DECL is not
abstract.  (Note that this function had no comment above it, and
therefore its intended interface constraints were non-obvious.  We
really need to write better documentation.  We also need to add more
assertions -- with comments -- in order to check that things are as we
expect.)  Is that correct?

    Jim> For efficiency reasons, you might want to put the
    Jim> DECL_ABSTRACT check higher up in the call chain.  If my
    Jim> analysis is right, then putting it in add_bound_info before
    Jim> the loc_descriptor_from_tree call should work.  

Right.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com