This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [DWARF] mark partial fn versions and OMP frags as partial in dwarf2+ debug info
- From: Jeff Law <law at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Cc: Jakub Jelinek <jakub at redhat dot com>
- Date: Tue, 21 Nov 2017 09:49:00 -0700
- Subject: Re: [DWARF] mark partial fn versions and OMP frags as partial in dwarf2+ debug info
- Authentication-results: sourceware.org; auth=none
- References: <ord14kyqbj.fsf@lxoliva.fsfla.org>
On 11/15/2017 12:05 AM, Alexandre Oliva wrote:
> debug info: partial noentry functions: infra
>
> This is the first patch of a set that addresses two different but
> somewhat related issues.
>
> On the one hand, after partial inlining, the non-inlined function
> fragment is output in a way that debug info consumers can't distinguish
> from the entire function: debug info lists the entire function as
> abstract origin for the fragment, but nothing that indicates the
> fragment does not stand for the entire function. So, if a debugger is
> asked to set a breakpoint at the entry point of the function, it might
> very well set one at the entry point of the fragment, which is likely
> not where users expect to stop.
>
> On the other hand, OpenMP blocks are split out into artificial functions
> that do not indicate their executable code is part of another function.
> The artificial functions are nested within the original function, but
> that's hardly enough: ideally, debug info consumers should be able to
> tell that, if they stop within one of these functions, they're
> abstractly within the original function.
>
> This patch introduces a new DWARF attribute to indicate that a function
> is a partial copy of its abstract origin, specifically, that its entry
> point does not correspond to the entry point of the abstract origin.
> This attribute can then be used to mark the out-of-line portion of
> partial inlines, and OpenMP blocks split out into artificial functions.
>
>
> This patchset was regstrapped on x86_64-linux-gnu and i686-linux-gnu.
>
> Ok to install the first patch? (infrastructure)
>
> Ok to install the second patch? (function versioning)
>
> Ok to install the third patch? (OpenMP fragments)
These look generally OK to me, but I'd like Jakub to chime in -- he's
got some state on the issues around OMP debugging and how it ought to be
structured.
Jakub, care to chime in?
jeff