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]
Other format: [Raw text]

Re: [DWARF] mark partial fn versions and OMP frags as partial in dwarf2+ debug info


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


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