similar to: DWARF: Ranges base address specifier entries & Gold's gdb-index 32 bit bug

On Tue, Aug 8, 2017 at 6:56 AM Nico Weber <thakis at chromium.org> wrote: > On Aug 7, 2017 6:58 PM, "David Blaikie" <dblaikie at gmail.com> wrote: > > Context: > > In r309526 (with a followup fix in r309529) I implemented the use of > DWARF's debug_ranges base address specifier entries to reduce the number of > object file relocations needed for

Adrian: any thoughts? Has LLDB been fixed to support this yet? On Tue, Aug 8, 2017 at 6:33 AM Robinson, Paul <paul.robinson at sony.com> wrote: > My inclination would be to use "disable if 32-bit and –ggnu-pubnames" as > the default, > Unfortunately Nico points out that Chrome doesn't currently use -ggnu-pubnames :/ So to continue to work "out of the box"

On Tue, Aug 8, 2017 at 10:50 AM Robinson, Paul <paul.robinson at sony.com> wrote: > Can gdb handle these? i.e. is it just gold that has the problem? > Yep, it's just gold when it's building the gdb-index (an accelerator table for GDB) > Conditioning on debugger tuning when it's not the debugger that has the > problem… icky. > It does. Though to a lesser

David Jones via llvm-dev <llvm-dev at lists.llvm.org> writes: > GDB likes to load all symbols from shared libraries up front. And on > x86_64 your main executable is really just another shared library. Yes, but does gdb reload everything on each execution? Every time I execute "run" I see the same slow behavior. Loading the symbols for small tools like llvm-rc takes

This is admittedly a longshot, but Can you check whether you experience unusually long run times with LLDB? If there’s something strange about tge binaries we generate, maybe lldb will exhibit some strangeness too and we can more easily profile it. On Wed, Jan 9, 2019 at 2:48 PM Shoaib Meenai via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don't know about the issues with

Yep, as others have mentioned - using a linker-generated gdb-index is super helpful (10s for my machine to start debugging an unoptimized clang, set a breakpoint at llvm::StringRef::StringRef and run until that breakpoint is hit, as opposed to 1m26s without an index) That's also with/without split DWARF too, but I suspect most of the benefit is in the index there. Split DWARF might save you

Hi,   We propose llvm-dwarfutil - a dsymutil-like tool for ELF.   Any thoughts on this?   Thanks in advance, Alexey. ====================================================================== llvm-dwarfutil(Apndx A) - is a tool that is used for processing debug info(DWARF) located in built binary files to improve debug info quality, reduce debug info size and accelerate debug info processing.

In short: Perhaps we should switch lld to the bfd-style tombstoning behavior for a release or two, letting users opt-in to testing with the new -1/-2 tombstoning in the interim, before switching to the new tombstone by default (while still having the flag to switch back when users find surprise places that can't handle the new behavior). In long: https://reviews.llvm.org/D81784 and follow-on

>On Fri, Jul 17, 2020 at 1:55 PM Alexey Lapshin <a.v.lapshin at mail.ru> wrote: >> >> >Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: >> > >> >On Fri, Jul 17, 2020 at 12:03 AM Fangrui Song <maskray at google.com> wrote: >> >> >> >> Thanks for the write-up! >> >> >>

>Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: > >On Fri, Jul 17, 2020 at 12:03 AM Fangrui Song < maskray at google.com > wrote: >> >> Thanks for the write-up! >> >> On 2020-07-16, David Blaikie wrote: >> >In short: Perhaps we should switch lld to the bfd-style tombstoning >> >behavior for a release or

>On Mon, Jul 20, 2020 at 10:32 AM Alexey Lapshin ><alapshin at accesssoftek.com> wrote: >> >> >On Fri, Jul 17, 2020 at 1:55 PM Alexey Lapshin <a.v.lapshin at mail.ru> wrote: >> >> >> >> >Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: >> >> > >> >> >On Fri, Jul 17, 2020 at

On 2020-07-24, Hans Wennborg via llvm-dev wrote: >Sounds good to me from a release perspective. I think we need more input from the triage of https://chromium-review.googlesource.com/c/chromium/src/+/2291352 whether it is just .debug_line or .debug_* >On Fri, Jul 24, 2020 at 7:53 AM Eric Christopher via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >> >> Hi All,

Hi All, In general I think we should adopt Dave's plan here. The number of consumers that can (and have) been caught off guard by this change is just too high. At the very least I think we should move this to opt in to the new tombstoning behavior by default and at most migrate to bfd's behavior for both the current release and in the current tree. If we want to make this sort of change

>From my understanding the breakpad bug was also only related to .debug_line and has been fixed by https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2317730 > a) .debug_ranges&.debug_loc => -2, .debug_line => 0, other .debug_* -> -1 > b) .debug_ranges&.debug_loc => -2, other .debug_* => 0 I am still of the opinion that we should just do a), not b).

On 2020-07-29, Eric Christopher wrote: >I think the arguments are largely compatibility for software that's already >deployed and can't easily upgrade, and wanting to ensure a larger time >frame for migration with a fallback if things go wrong. A bridge basically >from what we had to where we'd like to be. > >I think we also need to make the change in mainline lld as

Created https://reviews.llvm.org/D84825 to be used for release/11.x I haven't seen a strong argument for changing other .debug_* but in any case I don't want to continue debating on this topic. * .debug_ranges & .debug_loc: -2 (lld<11: 0+addend) * .debug_*: 0 (lld<11: 0+addend, lld HEAD: -1) On Mon, Jul 27, 2020 at 12:47 PM David Blaikie <dblaikie at gmail.com> wrote:

> I still think that we do bfd locs with a decent option to change for at least the current release and sources and then, once we're a little more certain we have everything that might want to parse dwarf (say by working with dwarf-discuss), we can change the default. Given what’s been found, I think Eric/Dave are correct, use bfd behavior by default with an option to do the new thing.

As I mentioned in the thread (to many people who don't have time to read the discussions), pushing https://reviews.llvm.org/D84825 restores the original behavior. The same effect as one would get by reverting all related patches. If someone gives me an approval, I'll push it immediately. I already get verbal LGTM from Peter. > With respect I think the "request for changes"

We have customers that rely on the symbol information from the "pubnames" section in the DWARF data. Generation of this information was removed in this commit: commit dfa30e1ab243990eda4732a6dffb91e965e7a755 Author: Eric Christopher <echristo at apple.com> Date: Wed Nov 9 05:24:07 2011 +0000 Remove the pubnames section, no one consumes it. git-svn-id:

Can we please just revert back to what we had before until the discussion about the desired behaviour and how to get there reaches a conclusion? In particular, I would like to merge that revert to the 11.x branch. At this point in the release process, I'm not keen on taking any patch that changes the behavior to something that hasn't been well tested from sitting in trunk for a while. On