Re: [PATCH] DWARF array bounds missing from C++ array definitions

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Sep 12, 2019 at 1:36 PM Alexandre Oliva <oliva@adacore.com> wrote:
>
> On Sep 12, 2019, Richard Biener <richard.guenther@gmail.com> wrote:
>
> > Is this PR91507?
>
> Looks like it.  Interesting, I've had this patch sitting in my tree
> since early June, waiting for the additional verification I completed
> last night.  That was long before the PR was filed.
>
> > How do you get around the gdb issue?
>
> I was not even aware of one.  I focused on preserving at what I regarded
> as the right place the information we currently dropped on the floor,
> figuring if any consumers wouldn't take the type information from the
> definition as overriding/completing that of the specification, they'd
> eventually be adjusted to do so.
>
>
> The approach I chose was to add the completion type to the definition,
> not to the specification.  I figured leaving the specification alone,
> reflecting the information available at its source location, and
> providing the complete type information at the source location that
> supplies it, was the right thing to do, regardless of whatever debug
> information consumers were able to do with that information.

Yes, I agree, this is what my patch in the PR does as well, albeit
just in the place where we add the link to the specification DIE
and the unconditionally if there's a disagreeing type DIE (we
force a type DIE earlier in the caller).  Your new predicate looks
a bit excessive here given it builds the type again?

But that's implementation detail I guess.

So I'm obviously fine with your patch and I guess if we independently
arrive at this solution that answers my question what "correct DWARF"
is by a majority decision ;)

So - maybe we can have the patch a bit cleaner by adding
a flag to add_type_attribute saying we only want it if it's
different from that already present (on the specification DIE)?

Thanks,
Richard.

> There's room for dispute as to the correctness of this approach,
> however.  Someone might argue that we should have a separate (IMHO
> excessive) completion non-defining declaration, pointing back to the
> initial incomplete declaration with a DW_AT_specification, and perhaps
> to omit the incomplete type from the incomplete specification, though
> that doesn't seem to be in line with the common practice of overriding
> declaration coordinates in the definition.
>
> --
> Alexandre Oliva, freedom fighter  he/him   https://FSFLA.org/blogs/lxo
> Be the change, be Free!       FSF.org & FSF Latin America board member
> GNU Toolchain Engineer                        Free Software Evangelist
> Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara