llvm dev - Mar 2017 - llvm-dev Digest, Vol 153, Issue 85

>FWIW - selfhosting I did find that GDB wasn't able to find the source
code
>for some functions when using LLD's gdb_index, so I've switched back
to
>gold+gdb_index for now (given the performance problems you mentioned,
>sounds like I wasn't gaining much/anything in terms of link time by
using
>lld anyway).
>
>On Thu, Mar 16, 2017 at 11:17 AM Rui Ueyama <ruiu at google.com>
wrote:
>
>> I personally haven't tried gdb_index, and I don't know the
quality of the
>> produced index. Most of the code was written by George.
>>
>> One thing I noticed about the feature (and filed as
>> http://bugs.llvm.org/show_bug.cgi?id=32228) is that our gdb_index
feature
>> is much slower than the gold. Apparently there's room for
improvement.
I also do not have information about quality of index. At simple tests output
was
equal to what gold produced for me.

I plan to start woring on PR32228 at next week, hope will be able to solve
perfomance
problems and may be it will reveal more details about index quality.

George.

On Fri, Mar 17, 2017 at 3:19 AM George Rimar <grimar at accesssoftek.com>
wrote:
> >FWIW - selfhosting I did find that GDB wasn't able to find the
source code
> >for some functions when using LLD's gdb_index, so I've switched
back to
> >gold+gdb_index for now (given the performance problems you mentioned,
> >sounds like I wasn't gaining much/anything in terms of link time by
using
> >lld anyway).
> >
> >On Thu, Mar 16, 2017 at 11:17 AM Rui Ueyama <ruiu at google.com>
wrote:
> >
> >> I personally haven't tried gdb_index, and I don't know the
quality of
> the
> >> produced index. Most of the code was written by George.
> >>
> >> One thing I noticed about the feature (and filed as
> >> http://bugs.llvm.org/show_bug.cgi?id=32228) is that our gdb_index
> feature
> >> is much slower than the gold. Apparently there's room for
improvement.
>
> I also do not have information about quality of index. At simple tests
> output was
> equal to what gold produced for me.
>
> I plan to start woring on PR32228 at next week, hope will be able to solve
> perfomance
> problems and may be it will reveal more details about index quality.
>
Sounds good - I took only a cursory glance at the llvm-dwarfdump of the
index, and it looked like (though I may be mistaken) the dump output
included implementation details (like hashes, buckets, etc) so it wasn't
easy to compare the dump from a GCC-built binary with a Clang-built binary
to compare them/see what was missing, etc.

Maybe it'd be worth having a mode that dumped the contents canonicalized
(sorted, etc) in some way that'd be easy to compare?

(then again, perhaps it's the structure that's the problem - maybe all
the
data's there, but there's a bug in the hashing that makes it
invalid/unable
for GDB to use it correctly)

Happy to try to help you with it.

- Dave

>
> George.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170317/25f01690/attachment.html>

>Sounds good - I took only a cursory glance at the llvm-dwarfdump of the
index, and it looked like (though I may be mistaken) the >dump output
included implementation details (like hashes, buckets, etc) so it wasn't
easy to compare the dump from a GCC-built >binary with a Clang-built binary
to compare them/see what was missing, etc.
>
>Maybe it'd be worth having a mode that dumped the contents canonicalized
(sorted, etc) in some way that'd be easy to
compare?

That is interesting idea. I'll try to build something large to see what
dumping mode can be usefull to add for doing comparsion tasks.
>(then again, perhaps it's the structure that's the problem - maybe
all the data's there, but there's a bug in the hashing that makes >it
invalid/unable for GDB to use it correctly)
>
>Happy to try to help you with it.
>
>- Dave
Yep, it probably can be something minor.
Thanks !

George.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170317/7527196b/attachment.html>