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

[Davide Italiano via llvm-commits]

On Thu, Oct 6, 2016 at 1:44 PM, George Rimar via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
>>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.
>
>

I have a slight preference for implementing the patch using LLVM, but
maybe that's just me. I'll let Eric/David comment further.

--
Davide