[PATCH] D24706: [ELF] - Partial support of --gdb-index command line option (Part 1).

[George Rimar via llvm-commits]

>On Thu, Oct 6, 2016 at 1:17 PM, George Rimar <grimar at accesssoftek.com> wrote:

>>>There's an assertion here that the current implementation is not fast or
>>> reusable. I'm not sure where that came from or what prompted it.
>>
>>>
>>>Could you elaborate more on why you think these things?
>>>
>>>-eric
>>
>> I am not saying it is not reusable, but it definetely now do a bit more than
>> we need in linker.
>> Citation of myself from one of previous mails:
>>
>> "short quick example:
>> Imaging I want to get address ranges and so I want to use
>> DWARFDebugInfoEntryMinimal::getAddressRanges(const DWARFUnit *U).
>> For doing that I need DWARFUnit, which requires DWARFContext in constructor.
>> Looking at comments that says
>> "DWARFContextInMemory is the simplest possible implementation of a
>> DWARFContext.", I am opening its constructor and
>> see that it takes an object and do a scan over all sections uncompresses the
>> compressed ones. But we do not need that as we already have
>> content of sections available."
>>
>> That this and possible other places need rework if we are want fastest
>> solution for lld.
>>
>
>I'm a little bit skeptical. It's not sure if the scan is a source of
>significant slowdown at link-time (it could possibly be, but we don't
>have the figures yet). Also, is there anything that prevents the API
>in LLVM to be changed so that the performance hit (if any) can be
>avoided? I'd rather try going that route, if possible.
>
>--
>Davide

It is not just scan. It uncompresses sections, what I think we do not need in linker as we should have them uncomressed already.
Then it tries to proccess relocations for many debug sections, what is also seems excessive for gdb_index section build needs.

To clarify - I am not trying to say it is slow (I did not compare or run benchmarks and I am not really familar with it), but I guess it should be slower
than what I do in the patch just because it do a bit more job now. What sure can be changed.

So Eric, David, if you guys think it is better to reimplement patch to reuse existent API - I think I am ready to try that.
If we can land patch as is and switch later - that also works for me.

George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161006/ddbea9f0/attachment.html>