From aoliva@redhat.com  Fri Aug 11 13:25:17 2017
From: aoliva@redhat.com (Alexandre Oliva)
Date: Fri, 11 Aug 2017 10:25:17 -0300
Subject: [Dwarf-Discuss] multiple entry points for inlined subroutines?
Message-ID: <orefsi2q4i.fsf@lxoliva.fsfla.org>

I've been working on generating more precise entry points for inlined
subroutines in GCC.

One of the goals of this was to provide the debug info consumer with a
view number, in addition to the address (more on that later), but
working on this, I found out that in several cases a single inlining of
a function ends up having some basic blocks replicated, including those
holding the entry point, and we have no way to represent the multiple
addresses.  This may often occur when a loop containing an inlined
function is unrolled, but it doesn't actually require unrolling: other
simpler CFG transformations that duplicate blocks in whole or in part
are enough to get some inlined entry points (but not necessarily entire
inlined functions) duplicated.

When an inlined function is duplicated as a whole, I guess it is just
reasonable to represent it as multiple inlinings of the same function,
this is not always the case: I have observed cases in which little more
than the entry point got duplicated into two separate branches.
However, even in the unrolling case, it is often the case that all
instances end up sharing the same automatic variables, except when the
intent is to have separate per-iteration variables for e.g. swing modulo
scheduling or other forms of iteration pipelining.  Such variable
replication comes with its own set of challenges, that I'm not focusing
on for the time being.  For now, I'm thinking of duplication of code
within the same subprogram without the introduction of additional copies
of variables.

In this scenario, each inlined function comes with its own set of
lexical blocks and local variables, even if unrolling and whatnot ends
up creating multiple copies of each use of such variables.

Ideally, I'd like to inform debug information consumers about all
inlined entry points, even when multiple such entry points are
associated with the same inlined instance of the function.  But AFAICT
DW_AT_entry_pc can only hold one address or offset.

I've considered several representations:

- multiple DW_AT_entry_pc attributes in the same DIE -> not permitted 2.2

- multiple lexical blocks with abstract origin pointing to the abstract
function, each with a separate entry point -> no good, the lexical block
tree will be misrepresented or replicated

- using an exprloc form, composing an array of entry addresses with
multiple DW_OP_piece expression -> not a very compact representation,
and hardly a natural extension

- abuse range lists having DW_AT_entry_pc reference one such list, with
two entry points per range entry -> not an unreasonable extension, but
readers might be confused if ranges are reversed, or if we have an odd
number of entry points

- likewise, but having a single entry point per range entry, wasting the
other address -> no problem with odd counts, but wasteful

- allow an address list form (addrptr class?) to be used in
DW_AT_entry_pc, with some convention to terminate the list -> this would
work AFAICT.  Is there any reason to not propose this for consideration
in DWARF6?

Any other thoughts on the isuse of representing multiple entry points
for an inlined subroutine, or even for lexical blocks or regular
subprograms?



On to adding view numbers to addresses.

I don't think it's just location list addresses and inline entry points
that could gain in precision being augmented with view numbers.  So far,
I have proposed an extension to record view numbers in location lists,
and I'm now introducing a GNU extended attribute to hold the view number
associated with an DW_AT_entry_pc in the same DIE.


One issue I'm running into is that view numbers are often computed by
the assembler, and encoded as uleb128 numbers.  GCC, however, wants to
compute the sizes and offsets of DIEs itself.  All existing sdata- and
udata-encoded attributes ever emitted by GCC are ones that it can
compute as constants itself; not so when it comes to view numbers.

Anyway, keeping DIE sizes compiler-computed constants is an issue I've
run into, and it becomes a larger concern once I start considering
proposing an attribute class that holds an address and a view.

Aside from the issue of compiler-computed DIE sizes and offsets, some
other lists that hold addresses want to be aligned, to simplify address
relocations and whatnot.  Once we add view numbers encoded as uleb128,
any hope for alignment is gone.  We might represent view numbers at the
same alignment, to keep them in the same sections, but that would likely
be wasteful.

Using a single indirect representations for both the address and the
view number, or a separate indirect reference to each, all have their
downsides, and even for long lists of such pairs, referencing a list of
addresses (good) and a list of views (erhm) so that corresponding
entries of each list are combined into tuples leaves something to be
desired.

I'd appreciate any thoughts on how to introduce compactly-represented
view numbers in most places where code addresses or address ranges could
be used.  Have these difficulties been run into before?  Any advice to
share?


Thanks in advance,

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


From aprantl@apple.com  Fri Aug 11 16:57:27 2017
From: aprantl@apple.com (Adrian Prantl)
Date: Fri, 11 Aug 2017 09:57:27 -0700
Subject: [Dwarf-Discuss] multiple entry points for inlined subroutines?
In-Reply-To: <orefsi2q4i.fsf@lxoliva.fsfla.org>
References: <orefsi2q4i.fsf@lxoliva.fsfla.org>
Message-ID: <72ED8CFB-3C25-4378-8E1C-104918D3F2FA@apple.com>

I'm unfamiliar with the term "view number". Is that a GCC-specific extension?

-- adrian

> On Aug 11, 2017, at 6:25 AM, Alexandre Oliva <aoliva at redhat.com> wrote:
> 
> I've been working on generating more precise entry points for inlined
> subroutines in GCC.
> 
> One of the goals of this was to provide the debug info consumer with a
> view number, in addition to the address (more on that later), but
> working on this, I found out that in several cases a single inlining of
> a function ends up having some basic blocks replicated, including those
> holding the entry point, and we have no way to represent the multiple
> addresses.  This may often occur when a loop containing an inlined
> function is unrolled, but it doesn't actually require unrolling: other
> simpler CFG transformations that duplicate blocks in whole or in part
> are enough to get some inlined entry points (but not necessarily entire
> inlined functions) duplicated.
> 
> When an inlined function is duplicated as a whole, I guess it is just
> reasonable to represent it as multiple inlinings of the same function,
> this is not always the case: I have observed cases in which little more
> than the entry point got duplicated into two separate branches.
> However, even in the unrolling case, it is often the case that all
> instances end up sharing the same automatic variables, except when the
> intent is to have separate per-iteration variables for e.g. swing modulo
> scheduling or other forms of iteration pipelining.  Such variable
> replication comes with its own set of challenges, that I'm not focusing
> on for the time being.  For now, I'm thinking of duplication of code
> within the same subprogram without the introduction of additional copies
> of variables.
> 
> In this scenario, each inlined function comes with its own set of
> lexical blocks and local variables, even if unrolling and whatnot ends
> up creating multiple copies of each use of such variables.
> 
> Ideally, I'd like to inform debug information consumers about all
> inlined entry points, even when multiple such entry points are
> associated with the same inlined instance of the function.  But AFAICT
> DW_AT_entry_pc can only hold one address or offset.
> 
> I've considered several representations:
> 
> - multiple DW_AT_entry_pc attributes in the same DIE -> not permitted 2.2
> 
> - multiple lexical blocks with abstract origin pointing to the abstract
> function, each with a separate entry point -> no good, the lexical block
> tree will be misrepresented or replicated
> 
> - using an exprloc form, composing an array of entry addresses with
> multiple DW_OP_piece expression -> not a very compact representation,
> and hardly a natural extension
> 
> - abuse range lists having DW_AT_entry_pc reference one such list, with
> two entry points per range entry -> not an unreasonable extension, but
> readers might be confused if ranges are reversed, or if we have an odd
> number of entry points
> 
> - likewise, but having a single entry point per range entry, wasting the
> other address -> no problem with odd counts, but wasteful
> 
> - allow an address list form (addrptr class?) to be used in
> DW_AT_entry_pc, with some convention to terminate the list -> this would
> work AFAICT.  Is there any reason to not propose this for consideration
> in DWARF6?
> 
> Any other thoughts on the isuse of representing multiple entry points
> for an inlined subroutine, or even for lexical blocks or regular
> subprograms?
> 
> 
> 
> On to adding view numbers to addresses.
> 
> I don't think it's just location list addresses and inline entry points
> that could gain in precision being augmented with view numbers.  So far,
> I have proposed an extension to record view numbers in location lists,
> and I'm now introducing a GNU extended attribute to hold the view number
> associated with an DW_AT_entry_pc in the same DIE.
> 
> 
> One issue I'm running into is that view numbers are often computed by
> the assembler, and encoded as uleb128 numbers.  GCC, however, wants to
> compute the sizes and offsets of DIEs itself.  All existing sdata- and
> udata-encoded attributes ever emitted by GCC are ones that it can
> compute as constants itself; not so when it comes to view numbers.
> 
> Anyway, keeping DIE sizes compiler-computed constants is an issue I've
> run into, and it becomes a larger concern once I start considering
> proposing an attribute class that holds an address and a view.
> 
> Aside from the issue of compiler-computed DIE sizes and offsets, some
> other lists that hold addresses want to be aligned, to simplify address
> relocations and whatnot.  Once we add view numbers encoded as uleb128,
> any hope for alignment is gone.  We might represent view numbers at the
> same alignment, to keep them in the same sections, but that would likely
> be wasteful.
> 
> Using a single indirect representations for both the address and the
> view number, or a separate indirect reference to each, all have their
> downsides, and even for long lists of such pairs, referencing a list of
> addresses (good) and a list of views (erhm) so that corresponding
> entries of each list are combined into tuples leaves something to be
> desired.
> 
> I'd appreciate any thoughts on how to introduce compactly-represented
> view numbers in most places where code addresses or address ranges could
> be used.  Have these difficulties been run into before?  Any advice to
> share?
> 
> 
> Thanks in advance,
> 
> -- 
> 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
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org



From aoliva@redhat.com  Wed Aug 16 19:29:35 2017
From: aoliva@redhat.com (Alexandre Oliva)
Date: Wed, 16 Aug 2017 16:29:35 -0300
Subject: [Dwarf-Discuss] multiple entry points for inlined subroutines?
In-Reply-To: <72ED8CFB-3C25-4378-8E1C-104918D3F2FA@apple.com> (Adrian Prantl's
	message of "Fri, 11 Aug 2017 09:57:27 -0700")
References: <orefsi2q4i.fsf@lxoliva.fsfla.org>
	<72ED8CFB-3C25-4378-8E1C-104918D3F2FA@apple.com>
Message-ID: <or7ey38g68.fsf@lxoliva.fsfla.org>

On Aug 11, 2017, Adrian Prantl <aprantl at apple.com> wrote:

> I'm unfamiliar with the term "view number". Is that a GCC-specific extension?

For now :-)  For an overview and links to further resources, including
the proposal to bring it into DWARF6, see
https://developers.redhat.com/blog/2017/07/11/statement-frontier-notes-and-location-views/

I'm going to speak about this at the upcoming GNU Tools Cauldron.

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


From paul.robinson@sony.com  Mon Aug 21 23:33:38 2017
From: paul.robinson@sony.com (Robinson, Paul)
Date: Mon, 21 Aug 2017 23:33:38 +0000
Subject: [Dwarf-Discuss] address pool + offset representation
In-Reply-To: <CAENS6Es3KJ3=5dn_auqaS-+fsNoMmUW28RaKgyEs7uRfc6t4=w@mail.gmail.com>
References: <CAENS6EvgnkgVgZ11JeagDtXE1i6s14nEnT_jNvZpOiQov1=ERA@mail.gmail.com>
	<CAENS6Ev7ZPLSvtGZpcP81q=jhW18yR97A1LFq36aehQaiUuC5A@mail.gmail.com>
	<CAENS6EtKFJ+bZBRi-+hkW4H9v-01Un4bRTPnc657SQRfKgPfVA@mail.gmail.com>
	<CADPb22STNsqPd+HU0GV6v+h6e4MkQ48k6iAn=xSE5JPVzNsOVg@mail.gmail.com>
	<CAENS6EtSJVAGPdYijZ6d0uE4koZ5R6bbBmUd6EL190QKbmk4bA@mail.gmail.com>
	<CADPb22QMVA7Hq3_1Ao8jbD=Xz58xgm43x0y2UUaKfjdgsCDvag@mail.gmail.com>
	<CAENS6EuPud9YP5mx_S7VCb-euv1XHvqZ-nd+t2covQ-rXfpQqQ@mail.gmail.com>
	<E3B07FDB86BFF041819DC057DEED8FEA01333E9658@USCULXMSG08.am.sony.com>
	<CAENS6EuTV-X7i0hrnXth83+X=+8_sqXb0bP3EO1E2Ug2u9Y-nQ@mail.gmail.com>
	<E3B07FDB86BFF041819DC057DEED8FEA01333E9724@USCULXMSG08.am.sony.com>
	<CAENS6Et-LZfoa06og5uyMVH=t_7UWu8iRh3UhAQKObcr3Y1m-Q@mail.gmail.com>
	<E3B07FDB86BFF041819DC057DEED8FEA01333E9C21@USCULXMSG08.am.sony.com>
	<CAENS6Es7GhE6q-3WJC5PRPoCiJ72KRjst6R1h8MwGKzyO1uUbg@mail.gmail.com>
	<E3B07FDB86BFF041819DC057DEED8FEA01333EB4A1@USCULXMSG08.am.sony.com>
	<CAENS6Es3KJ3=5dn_auqaS-+fsNoMmUW28RaKgyEs7uRfc6t4=w@mail.gmail.com>
Message-ID: <E3B07FDB86BFF041819DC057DEED8FEA013346692C@USCULXMSG08.am.sony.com>

>>> I don't really know just how much LLDB cares about fixed-size forms/DIEs,
>>> but rumor has it it's important to some degree, so I continue to have a
>>> slight preference towards fixed size representations (or at least having
>>> the option to do so, even if there are variable length forms too - as
>>> with addrx).
>>
>> Greg Clayton has told me it's a performance win for loading .debug_info.
>> They can index fixed-size DIEs without actually parsing them.? When I
>> proposed the fixed-size strx/addrx forms to the committee, I did some
>> data collection on the effect of strx and addrx.? Converting to strx
>> meant fixed size DIEs went from 90-ish to 55-ish percent of all DIEs,
>> so fixed-size strxN forms were definitely worthwhile.? The equivalent
>> analysis for addrx showed a difference of more like 4%, which was
>> enough to persuade the committee that would be worthwhile also.
>
> I imagine the same would be true of ranges in an optimized build? (Maybe
> a little lower, but not by much) 'spose, as you say, we can always add
> rnglistxN in the future.
?
It could be helpful there, I did not try to do any measurements.
--paulr



From dblaikie@gmail.com  Wed Aug 23 01:25:15 2017
From: dblaikie@gmail.com (David Blaikie)
Date: Wed, 23 Aug 2017 01:25:15 +0000
Subject: [Dwarf-Discuss] address pool + offset representation
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEA01333EB4A1@USCULXMSG08.am.sony.com>
References: <CAENS6EvgnkgVgZ11JeagDtXE1i6s14nEnT_jNvZpOiQov1=ERA@mail.gmail.com>
	<CAENS6Ev7ZPLSvtGZpcP81q=jhW18yR97A1LFq36aehQaiUuC5A@mail.gmail.com>
	<CAENS6EtKFJ+bZBRi-+hkW4H9v-01Un4bRTPnc657SQRfKgPfVA@mail.gmail.com>
	<CADPb22STNsqPd+HU0GV6v+h6e4MkQ48k6iAn=xSE5JPVzNsOVg@mail.gmail.com>
	<CAENS6EtSJVAGPdYijZ6d0uE4koZ5R6bbBmUd6EL190QKbmk4bA@mail.gmail.com>
	<CADPb22QMVA7Hq3_1Ao8jbD=Xz58xgm43x0y2UUaKfjdgsCDvag@mail.gmail.com>
	<CAENS6EuPud9YP5mx_S7VCb-euv1XHvqZ-nd+t2covQ-rXfpQqQ@mail.gmail.com>
	<E3B07FDB86BFF041819DC057DEED8FEA01333E9658@USCULXMSG08.am.sony.com>
	<CAENS6EuTV-X7i0hrnXth83+X=+8_sqXb0bP3EO1E2Ug2u9Y-nQ@mail.gmail.com>
	<E3B07FDB86BFF041819DC057DEED8FEA01333E9724@USCULXMSG08.am.sony.com>
	<CAENS6Et-LZfoa06og5uyMVH=t_7UWu8iRh3UhAQKObcr3Y1m-Q@mail.gmail.com>
	<E3B07FDB86BFF041819DC057DEED8FEA01333E9C21@USCULXMSG08.am.sony.com>
	<CAENS6Es7GhE6q-3WJC5PRPoCiJ72KRjst6R1h8MwGKzyO1uUbg@mail.gmail.com>
	<E3B07FDB86BFF041819DC057DEED8FEA01333EB4A1@USCULXMSG08.am.sony.com>
Message-ID: <CAENS6EuiZindAcNKNF7U3Zv+C3JBB7i27REFyMab+cOj6XAtRg@mail.gmail.com>

Coming back to this part of the thread...

On Thu., 27 Jul. 2017, 11:54 am Robinson, Paul <paul.robinson at sony.com>
wrote:

>
>                       |
> > I don't really know just how much LLDB cares about fixed-size forms/DIEs,
> > but rumor has it it's important to some degree, so I continue to have a
> > slight preference towards fixed size representations (or at least having
> > the option to do so, even if there are variable length forms too - as
> > with addrx).
>
> Greg Clayton has told me it's a performance win for loading .debug_info.
> They can index fixed-size DIEs without actually parsing them.  When I
> proposed the fixed-size strx/addrx forms to the committee, I did some
> data collection on the effect of strx and addrx.  Converting to strx
> meant fixed size DIEs went from 90-ish to 55-ish percent of all DIEs,
> so fixed-size strxN forms were definitely worthwhile.  The equivalent
> analysis for addrx showed a difference of more like 4%, which was
> enough to persuade the committee that would be worthwhile also.


Here ^ I'd I'm following, you mention that 4% fewer fixed size DIEs was
enough to justify having fixed size forms of addrx - if I'm reading that
right?

 If

we go with the low_pc-as-range idea then adding fixed-size versions of
> rnglistx in DWARF 6 would not be a problem.
>
> The advantage of what the ranges idea is it can all be done using
> exiting DWARF 5 features.
>
> > at that point I wouldn't mind a form that was two ULEBs (addrx + offset).
>
> Might as well just allow DW_AT_low_pc to use a location expression?
>   DW_OP_addrx <n> DW_OP_constx <offset> DW_OP_plus
> This would be way more acceptable than a new special-purpose form.
> Still bigger than a new form, of course, but as I noted above only 4%
> of DIEs become variable size so that penalty doesn't seem excessive.
>

And here ^ you're suggesting 4% fewer fixed size DIEs would be acceptable?

Did I misunderstand one of those or a step between them?

In any case, maybe I'll see if Doug and other folks on gdb would be willing
to entertain support for location expressions in address kind attributes &
then use the general expression at least as a first blush. It seems a bit
can-of-wormsy though.

- Dave

3 bytes plus 3 LEBs, so only 3 bytes + 1 LEB more than the new form,
> and still cheaper than the ranges idea.
> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20170823/e89e433f/attachment.htm>


