search for: debug_ful

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

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"

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

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

On 2020-11-17, Igor Kudrin wrote: > >On 17.11.2020 14:05, Fāng-ruì Sòng wrote: >>On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: >>> >>>On 14.11.2020 3:42, Fāng-ruì Sòng wrote: >>>>For .debug_* in object files: >>>> >>>>DWARF32 -> SHT_PROGBITS (unchanged) >>>>DWARF64 ->

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 Sat, May 30, 2020 at 8:50 PM Fangrui Song <maskray at google.com> wrote: > > On 2020-05-29, David Blaikie wrote: > >On Fri, May 29, 2020 at 2:20 PM Robinson, Paul <paul.robinson at sony.com> wrote: > >> > On Fri, May 29, 2020 at 9:21 AM Robinson, Paul <paul.robinson at sony.com> > >> > wrote: > >> > > > On 2020-05-28, David

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

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 Fri, May 29, 2020 at 2:20 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Friday, May 29, 2020 5:00 PM > > To: Robinson, Paul <paul.robinson at sony.com> > > Cc: Fangrui Song <maskray at google.com>; Alexey Lapshin > >

On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: > > On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > > For .debug_* in object files: > > > > DWARF32 -> SHT_PROGBITS (unchanged) > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > > all

On Sun, May 31, 2020 at 9:57 AM Fangrui Song <maskray at google.com> wrote: > > > On 2020-05-30, David Blaikie wrote: > >On Sat, May 30, 2020 at 8:50 PM Fangrui Song <maskray at google.com> wrote: > >> > >> On 2020-05-29, David Blaikie wrote: > >> >On Fri, May 29, 2020 at 2:20 PM Robinson, Paul <paul.robinson at sony.com> wrote: >

On 2020-05-28, David Blaikie wrote: >On Thu, May 28, 2020 at 2:52 PM Robinson, Paul <paul.robinson at sony.com> >wrote: > >> As has been mentioned elsewhere, Sony generally fixes up references from >> debug info to stripped functions (of any length) using -1, because that’s a >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base >>

On Fri, May 29, 2020 at 9:21 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: Fangrui Song <maskray at google.com> > > Sent: Friday, May 29, 2020 1:07 AM > > To: David Blaikie <dblaikie at gmail.com> > > Cc: Robinson, Paul <paul.robinson at sony.com>; Alexey Lapshin > >

My concern with using section type, is that it does modify ELF format spec, and can break various tools that rely on this information. This sems somewhat of a heavy handed approach to solving this problem. Alternatively, if we do want to go with something more official then just doing it in a linker using first reloc, why not use sh_info? Seems like it's made for providing an extra

> Subject: Re: [llvm-dev] Range lists, zero-length functions, linker gc > > On 2020-05-28, David Blaikie wrote: > >On Thu, May 28, 2020 at 2:52 PM Robinson, Paul <paul.robinson at sony.com> > >wrote: > > > >> As has been mentioned elsewhere, Sony generally fixes up references > from > >> debug info to stripped functions (of any length) using

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Rafael Espíndola > Sent: Monday, April 27, 2015 2:07 PM > To: Jack Howarth > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] __eh_frame info changes in Clang? > > That looks like a bug. > > From > >

In https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ (you need to join the group before making a post) Cary Coutant raised yet another idea: whether we can use ".debug64" as the section prefix. I like the idea because of: * It is immediately obvious whether DWARF64 is used and whether DWARF32 is used along with DWARF64. * In a relocatable link mixing DWARF32 and DWARF64 sections,

On 2020-11-14, Alexander Yermolovich wrote: >Thanks for doing a diff and asking in other groups. > >So if I understand your concern with using first reloc as it relates to .debug_str. > >In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some

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