llvm dev - Jan 2018 - [lldb-dev] Adding DWARF5 accelerator table support to llvm

> On Jan 18, 2018, at 7:52 AM, Pavel Labath via lldb-dev <lldb-dev at
lists.llvm.org> wrote:
> 
> Thank you for all the responses. Unfortunately I wasn't able to make
> any progress on creating the patches today. I'll be sure to add
> everyone who expressed interest here to the phabricator diff once I
> have them ready.
> 
> Jonas, do you have any dsymutil patches I can look at? I am interested
> in seeing what kind of interfaces are you using, particularly on the
> reading side. I think the current DWARFAcceleratorTable interface will
> need to be redesigned a bit if we want it to fit the dwarf5 tables as
> well.
Dsymutil never reads accelerator tables. It rebuilds them while walking the
debug_info section.

Fred
> On 17 January 2018 at 20:52, Eric Christopher via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
>> FWIW I'm completely on board with everything Adrian has said in
this thread
>> :)
>> 
>> -eric
>> 
>> On Wed, Jan 17, 2018 at 11:00 AM Adrian Prantl via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> 
>>> 
>>>> On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev
>>>> <llvm-dev at lists.llvm.org> wrote:
>>>> 
>>>> As mentioned by Adrian in the comment you linked, I too am
looking at
>>>> DWARFv5
>>>> accelerator tables in LLVM.
>>>> 
>>>> To give you some background: my motivation is that I want to
upstream
>>>> support
>>>> for (Apple style) accelerator tables in llvm-dsymutil,
>>> 
>>> Some background for the benefit of everyone who may not be aware of
the
>>> genesis of the DWARF v5 accelerator tables:
>>> 
>>> DWARF v5 accelerator tables are a direct evolution of the
"Apple"
>>> accelerator tables that are implemented in LLVM (after going
through the
>>> standardization process and being reworked/generalized there), so
we hope
>>> that the implementation can at least share some common interfaces
with the
>>> existing Apple accelerator table implementation where this makes
sense.
>>> 
>>> -- adrian
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Hello all,

I am looking for feedback regarding implementation of the case folding
algorithm for .debug_names hashes.

Unlike the apple tables, the .debug_names hashes are computed from
case-folded names (to enable case-insensitive lookups for languages
where that makes sense). The dwarf5 document specifies that the case
folding should be done according the the "Caseless matching" Section
of the Unicode standard (whose implementation is basically a long list
of special cases). While certainly possible, implementing this would
be much more complicated (and would probably make the code a bit
slower) than a simple tolower(3) call. And the benefits of this are
not really clear to me.

Do you know if we already make any promises or assumptions about the
encoding and/or locale of the symbol names (and here I mainly mean the
names in the debug info metadata, not llvm symbols).

If we don't already have a policy about this, then I propose to
implement the case folding via tolower() (which is compatible with the
full case folding algorithm, as long as one sticks to basic latin
characters).

What do you think?

> On Jan 30, 2018, at 7:35 AM, Pavel Labath <labath at google.com>
wrote:
> 
> Hello all,
> 
> I am looking for feedback regarding implementation of the case folding
> algorithm for .debug_names hashes.
> 
> Unlike the apple tables, the .debug_names hashes are computed from
> case-folded names (to enable case-insensitive lookups for languages
> where that makes sense). The dwarf5 document specifies that the case
> folding should be done according the the "Caseless matching"
Section
> of the Unicode standard (whose implementation is basically a long list
> of special cases). While certainly possible, implementing this would
> be much more complicated (and would probably make the code a bit
> slower) than a simple tolower(3) call. And the benefits of this are
> not really clear to me.
Assuming a UTF-8 encoding, will tolower(3) destroy any non-ASCII characters in
the process? In Swift, for example, we allow a wide range of unicode characters
in identifiers and I want to make sure that this doesn't cause any problems.

-- adrian
> 
> Do you know if we already make any promises or assumptions about the
> encoding and/or locale of the symbol names (and here I mainly mean the
> names in the debug info metadata, not llvm symbols).
> 
> If we don't already have a policy about this, then I propose to
> implement the case folding via tolower() (which is compatible with the
> full case folding algorithm, as long as one sticks to basic latin
> characters).
> 
> What do you think?

> On Jan 30, 2018, at 3:35 PM, Pavel Labath <labath at google.com>
wrote:
> 
> Hello all,
> 
> I am looking for feedback regarding implementation of the case folding
> algorithm for .debug_names hashes.
> 
> Unlike the apple tables, the .debug_names hashes are computed from
> case-folded names (to enable case-insensitive lookups for languages
> where that makes sense). The dwarf5 document specifies that the case
> folding should be done according the the "Caseless matching"
Section
> of the Unicode standard (whose implementation is basically a long list
> of special cases). While certainly possible, implementing this would
> be much more complicated (and would probably make the code a bit
> slower) than a simple tolower(3) call.
Most of the characters in the CaseFolding.txt file seem to be contiguous, so I
think we should be able to come up with am implementation that’s relatively
efficient.
> And the benefits of this are not really clear to me.
Adhering to the standard is a pretty big benefit IMHO, but I know what you mean.
:-)
> Do you know if we already make any promises or assumptions about the
> encoding and/or locale of the symbol names (and here I mainly mean the
> names in the debug info metadata, not llvm symbols).
> 
> If we don't already have a policy about this, then I propose to
> implement the case folding via tolower() (which is compatible with the
> full case folding algorithm, as long as one sticks to basic latin
> characters).
> 
> What do you think?