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

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 21, 2017, Jakub Jelinek <jakub@redhat.com> wrote:

> On Wed, Nov 15, 2017 at 05:05:36AM -0200, Alexandre Oliva wrote:

>> 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.

> I'm not sure I like the attribute name too much, and more importantly,
> as I said before, I think the attribute should not be a flag, but a number
> which tells not just that it is an outlined portion of the original
> subprogram, but also what kind of outlining it is and its purpose.

I suppose you don't like it because it means something other than what
you suggested.  I'd taken note of your suggestion, and even asked for
more details back then, but none of the debug info consumers seemed to
have changed their mind to the initial assessment that a single boolean
flag would suffice for the purposes of telling whether or not the entry
point of a given (implementation) subprogram should be covered by a
breakpoint at a given (source-level) subprogram.

We could supply a lot more detail about how functions are split, and
why, but if debug info consumers have no way to make use of the info, or
have no interest in doing so, I don't see that makes sense to waste
compiler resources preserving and generating such additional
information.

This flag serves a simple purpose that doesn't require debug info
consumers to understand the implications of such relationships as a
function having multiple openmp blocks split out of it, before being
further split into inline and out-of-line, and then have the out-of-line
portion further versioned and then split into inline and out-of-line.
A debug info consumer can deal with that regardless of our providing
additional detail about the purpose of the splits elsewhere.

Now consider that we mark both inline and out-of-line functions with the
same attribute and different nonzero values, and that we assign
different values for the various kinds of split-out blocks, some of
which a debug info consumer doesn't know about.  Should it then stop at
the entry point of that fragment when a breakpoint is set on a function,
or should it not?  (if there's more than one nonzero value for which the
fragment encompasses the entry point, a conservative debug info consumer
won't know what to do)

So, you see, the additional amount of detail, along with its future
expansion, actually gets in the way of solving the one problem I've set
out to solve.

What's more, there's active interest in using the information supplied
by the patchset I posted, whereas no debug info consumer (so far, at
least) has reacted to your suggestion that we produce the additional
layer of detail.  And yet, should such interest appear at any time, we
could added it, as a separate attribute, so that it does NOT counter the
purpose of the partial_noentry attribute, providing instead just
additional detail.  The existence of the partial_noentry boolean
attribute will then not even cost anything extra: it will always go
together with the additional attribute or attributes that supply the
additional information that consumers might wish us to supply, so that
the boolean flag will just be an entry in the abbrev tables always next
to the extra-detail attribute.

> The advantage of having more details is that the debug info consumer can
> then decide how to handle, say talk to OMPD to find out the parent thread,
> or look it up inside of libgomp (say through infinity notes), whatever.

I'm afraid I still don't see what would be achieved with that, but I
suspect that if there's useful debug info consumer behavior to be
achieved, this one bit or enum won't suffice.  That being the case, I
suspect the additional information on top of the enum might very well
turn out to be enough along with the bit as well.  But this is all
speculation on my part: I'm not aware of demands from debug info users
or consumers for whatever you have in mind, and thus I certainly haven't
taken any such demands into account.  The demands I had were to provide
debug info consumers with a way to avoid setting unexpected breakpoints
at out-of-line fragments of partial inlines, and I realized the same
problem could affect openmp split-out blocks as well.  I have consulted
with debug info consumers about the presently proposed solution, and
other more detailed ones, and the simpler one is what came out ahead.

> And we could in the future add other kinds if we start outlining for other
> reasons.

Please realize that this possibility would make their jobs harder,
unless it is implemented as an add-on to the present one (i.e., another
attribute).  For this reason, I suggest we put this more detailed
suggestion aside until such time as debug info consumers display
interest in using such information.  Then, we proceed to design a proper
solution that provides them with *all* the required information to
implement the debugging plans you have in mind.  But throwing in more
detail just because we could, in the hope it might be useful, in this
case will actually fail to address the problem at hand.

Does that work for you?

Thanks,

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer