similar to: DWARF debug line error handling changes

On Mon, 27 Jan 2020 at 23:22, David Blaikie <dblaikie at gmail.com> wrote: > Thanks for all the work & context, James! > Thanks for the reviews! > > On Mon, Jan 27, 2020 at 5:51 AM James Henderson < > jh7370.2008 at my.bristol.ac.uk> wrote: > >> Hi all, >> >> Since December, I've made several changes to the DWARF debug line parser

On Wed, Nov 11, 2020 at 12:55 AM James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > > > On Wed, 11 Nov 2020 at 05:41, David Blaikie <dblaikie at gmail.com> wrote: >> >> +James for context too (always good to include the folks from the >> original threads for continuity) >> >> Yeah, my general attitude there was just twofold, one that

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

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:

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

>Пятница, 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

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

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"

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

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

>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

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

Honestly even though I do understand the debug information I'm with you and one reason why I'm pushing for the same reset that you are. There are a lot of threads, it's fairly confusing what has been done where and other than some fairly widespread breakage among early users of lld (i.e. a short time from commit to use) it's unclear what the plan is to roll this out effectively

(Adding back Cc: which got dropped) > (Igor - I don't know what happened, but your email split the mail thread in gmail for me.) The problem is that https://lists.llvm.org/pipermail/llvm-dev/2020-November/146528.html does not have an In-Reply-To: header. Added Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer

+James for context too (always good to include the folks from the original threads for continuity) Yeah, my general attitude there was just twofold, one that the discussion had strayed fairly far from the review (so interested parties might not see it, both because it's a targeted review thread on the noisy llvm-commits, and because fo the title not having much connection to the discussion)

On Thu, Jun 4, 2020 at 8:27 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Wednesday, June 3, 2020 5:31 PM > > To: Robinson, Paul <paul.robinson at sony.com> > > Cc: jh7370.2008 at my.bristol.ac.uk; llvm-dev at lists.llvm.org > >

On Wed, Aug 5, 2020 at 12:50 PM Fāng-ruì Sòng <maskray at google.com> wrote: > On Wed, Aug 5, 2020 at 12:32 PM Eric Christopher <echristo at gmail.com> > wrote: > > > > Honestly even though I do understand the debug information I'm with you > and one reason why I'm pushing for the same reset that you are. There are a > lot of threads, it's fairly

"On Thu, Jun 4, 2020 at 3:11 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > + Ben Dunbobbin, whose name I take in vain below. > He's my local expert on weird ELF features. > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Thursday, June 4, 2020 2:43 PM > > To: Robinson, Paul