On Nov 21, 2017, Jakub Jelinek <ja...@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
