Re: [PR84620] output symbolic entry_view as data2, not addr

[Jakub Jelinek <jakub@redhat.com>]

On Tue, Mar 06, 2018 at 03:13:11AM -0300, Alexandre Oliva wrote:
> On Mar  2, 2018, Alexandre Oliva <aoliva@redhat.com> wrote:
> 
> > Mark Wielaard is implementing support for LVU and IEPM in elfutils, and
> > he was surprised by the encoding of DW_AT_GNU_entry_view; so was I!
> > When GCC computes and outputs views internally (broken without internal
> > view resets), it outputs entry_view attributes as data: it knows the
> > view numbers.  However, when it uses the assembler to compute the views
> > symbolically, it has to output the view symbolically.
> 
> > I'd chosen lbl_id to that end, without giving it much thought, but that
> > was no good: it's not just space-inefficient, it uses an addr encoding,
> > indirect in some cases, for something that's not a real label, but
> > rather a a small assembler data constant.  Oops.
> 
> Jakub wrote (in the BZ):
> 
> > I meant to say:
> > The char * GTY ((tag ("dw_val_class_symview"))) val_symbolic_view; line 
> > should come at the and of the union, not before the other classes.
> 
> I've moved the union field down in the revised patch below, but I don't
> see the point, and I thought it would be better to keep it close to
> logically-similar entries.  If the point is just to make it parallel to
> the order of the enum (which manh other entries don't seem to have cared
> about), maybe moving the enum would be better?

I think the order should match the order of the dw_val_class entries and
should be sorted from the most commonly used ones (ones used by most
different attributes etc.), so that somebody trying to learn dwarf2out
stuff can learn it more easily (say the dw_val_class_const,
dw_val_class_const_unsigned, dw_val_class_flag first etc.), but apparently
it is completely random already, I'll defer to Jason what he wants.

> > What guarantees the symview symbols always fit into 16 bits?  Does 
> > something    punt if it needs more than 65536 views?
> 
> There's no guarantee it will fit in 16 bits; the assembler will warn if
> it truncates a view number.  There's no real upper limit, so uleb128
> would be ideal, but since that's not viable ATM, I had to pick
> something, and 16 bits would cover all really useful cases than 32 or
> even 64 bits would, while being more compact.  I was even tempted to go
> with 8 bits, but thought that was pushing it.  I can make it 32 if you
> consider it better.  Or maybe a param?

I'm afraid I haven't understood yet why we need labels instead of compiler
assigned numbers for the views, so not really sure I can answer this.
Can the compiler count how many different view labels it has produced or
will produce, or at least compute easily an upper bound, and decide on the
form based on that?  Or what will exactly happen if you use too small form?
Silent wrong-debug, assembler error, something else?

> > The FIXMEs don't really look helpful, we are not going to change the 
> > offset computation from compile time to assemble time, that would be 
> > terribly expensive.
> 
> Why do you say it would be terribly expensive to let the assembler compute
> offsets in .debug_info?

Because people are already complaining about slow assembly times of debug
info, and offsets are used pretty much everywhere in .debug_info.
With some assemblers that don't allow .uleb128/.sleb128 that is impossible
to do, with others you'd need to emit a new label before every DIE and all
DW_AT_type and many others would need to use .LD123456-.LD1092456 kind of
expressions which assembler would need to parse and resolve
(DW_FORM_ref{1,2,4,8,_udata}).

	Jakub