[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

My main point was that we can land this ready patch and then switch to LLVM API.
And do a benchmarks during doing that to see if there iny boost or slowdowns.
Because patch as I mentioned looks to be ready and nothing stops us from this way.
If you think that is excessive step and it is better to reimplement whole patch to use the LLVM API first,
I can try to do that.

George.

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