search for: d84825

...ward is going to be the process that's easiest > understood for everyone. > > > > Thanks! > > > > -eric > > > > On Wed, Aug 5, 2020 at 12:13 PM Hans Wennborg <hans at chromium.org> wrote: > >> > >> My apologies, I didn't realize D84825 now restores the original > >> behavior. The review thread is a bit hard to follow :-) > >> > >> From the change description it still sounds like .debug_ranges & > >> .debug_loc tombstones are changing to -2 though? Or is that what we > >> had before...

...oing on now that it seems like resetting back to default for lld and then moving forward is going to be the process that's easiest understood for everyone. Thanks! -eric On Wed, Aug 5, 2020 at 12:13 PM Hans Wennborg <hans at chromium.org> wrote: > My apologies, I didn't realize D84825 now restores the original > behavior. The review thread is a bit hard to follow :-) > > From the change description it still sounds like .debug_ranges & > .debug_loc tombstones are changing to -2 though? Or is that what we > had before? > > To be clear, I'm not familiar...

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" blocked the change and I am not incl...

...alloc= has somewhat a larger chance that it can >> be adopted by other linkers) and will go away in two or three releases. >> >> >On Tue, Jul 28, 2020 at 10:00 PM Fāng-ruì Sòng <maskray at google.com> wrote: >> > >> >> 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<1...

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...

...ld/gold/LLD difference (-z dead-reloc-in-nonalloc= has somewhat a larger chance that it can be adopted by other linkers) and will go away in two or three releases. >On Tue, Jul 28, 2020 at 10:00 PM Fāng-ruì Sòng <maskray at google.com> wrote: > >> 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<1...

...to dsymutil. Though if there is a preference to implement it as part of dsymutil we are OK to do this way. In its first version, this new utility supposed to receive built binary with debug info as input(with the new marking for references to removed code sections -1/-2 -https://reviews.llvm.org/D84825) and create a new binary with removed obsolete debug info according to the above marking. In the next versions, it could be extended with other debug info optimizations tasks. F.e. generation new index tables, debug info optimizing... etc... We considered three options: 1. add new functionalit...

...and extending that seems straight forward, however... > > >> In its first version, this new utility supposed to receive built binary >> with debug info >> as input(with the new marking for references to removed code sections >> -1/-2 >> -https://reviews.llvm.org/D84825) and create a new binary with removed >> obsolete >> debug info according to the above marking. In the next versions, it could >> be extended >> with other debug info optimizations tasks. F.e. generation new index >> tables, debug info >> optimizing... etc... &gt...

...xtending that seems straight forward, however... >> >>> >>> In its first version, this new utility supposed to receive built binary with debug info >>> as input(with the new marking for references to removed code sections -1/-2 >>> -https://reviews.llvm.org/D84825) and create a new binary with removed obsolete >>> debug info according to the above marking. In the next versions, it could be extended >>> with other debug info optimizations tasks. F.e. generation new index tables, debug info >>> optimizing... etc... >>> >&...

> 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.

On 28.07.2020 19:28, David Blaikie wrote: > On Tue, Jul 28, 2020 at 8:55 AM Alexey Lapshin <avl.lapshin at gmail.com> wrote: >> >> On 28.07.2020 10:29, David Blaikie via llvm-dev wrote: >>> On Fri, Jun 26, 2020 at 9:28 AM Alexey Lapshin >>> <alapshin at accesssoftek.com> wrote: >>>>>>>>>>>> This idea goes in another