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] DWARF array bounds missing from C++ array definitions

On Thu, Sep 12, 2019 at 1:36 PM Alexandre Oliva <> wrote:
> On Sep 12, 2019, Richard Biener <> 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)?


> 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
> Be the change, be Free! & FSF Latin America board member
> GNU Toolchain Engineer                        Free Software Evangelist
> Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara

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