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

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar  6, 2018, Jakub Jelinek <jakub@redhat.com> wrote:

> I'm afraid I haven't understood yet why we need labels instead of compiler
> assigned numbers for the views,

The compiler can't determine points at which the insn address changes
reliably (or at all).  It's impossible in the general case, considering
that alignment requests might be fulfilled by an assembler without any
address change, if the current address was just right, and only the
assembler would know that.

> Can the compiler count how many different view labels it has produced or
> will produce

It can do that, yeah.  We could even count the max estimated view
number, which, in the absence of view reset points (the compiler has
that disabled except on ports that define a target hook to enable it,
and none do), is equivalent to the number of views.  I guess this is a
reasonable upper bound to use, in the absence of a closer estimate.
I'll give it a shot.


> Or what will exactly happen if you use too small form?
> Silent wrong-debug, assembler error, something else?

>> the assembler will warn if it truncates a view number

Wrong-debug, but not silent.  Not an error either.


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

They're used pretty much everywhere in code as well; I suspect we have a
lot more labels in code than we'd have within debug info.

As to complaints...  are those recent, possibly related with
https://sourceware.org/bugzilla/show_bug.cgi?id=22870
or were the complains already in place before LVU went in?

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

Assemblers determine addresses for labels all the time, and surely
computing offsets between them, when they're in the same section, can't
be that expensive.  Well, with relaxable frags whose sizes depend on the
offsets, it could in theory get expensive indeed, but would it in
practice?


I can see that mandatory [us]leb128 fields could be a problem, but are
there any fields that involve offsets into .debug_info, and that must be
represented as [us]leb128?  I don't think so.

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