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

[Eric Christopher via llvm-commits]

On Thu, Oct 6, 2016 at 3:55 PM George Rimar <grimar at accesssoftek.com> 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
>
> It is not just scan. It uncompresses sections, what I think we do not need
> in linker as we should have them uncomressed already.
>

What should be decompressing them?


> Then it tries to proccess relocations for many debug sections, what is
> also seems excessive for gdb_index section build needs.
>

This is probably true though. (Mostly, you'll need to resolve some of the
relocations in the compile unit).


>
> 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.
>
>
I'd prefer not to have any more debug readers than necessary. If you need
additional API entry points in the debug information it seems like a good
idea to add them as well.

Thanks!

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