similar to: [LLVMdev] duplicate .debug_line sections

Please unsubscribe me from this list. Sujatha Gurumurthy Staffing Consultant/Talent Advisor UMG - Ultra Mobile Group sujatha.gurumurthy at intel.com US ERP Manager Interested in Employee Referral Program Visit referral.intel.com/ Intel USA Employee Referral Program Group 100 Best Companies to Work For 2011: Intel - INTC - from FORTUNE -----Original Message----- From: llvmdev-bounces at

Dear all, I'm trying to use the gold plugin to make it easier to generate LLVM bitcode from complex applications. I did the steps mentioned on "http://llvm.org/docs/GoldPlugin.html". Both linking and LLVM generation seem to work properly, however when using the tool ar, the symbol table is lost. "no archive symbol table (run ranlib)". I'm using LLVM 2.9, Ubuntu 10.10,

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

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

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

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

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

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

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

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

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"

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

I've noticed that lld keeps the data section more isolated than the gold or bfd linkers. For example, readelf -l applied to the "same" executable linked with those three linkers reveals the following under "Section to Segment mapping": lld: 05 .data .got.plt .bss gold: 03 .eh_frame .init_array .fini_array .preinit_array .dynamic .got .got.plt .data .bss bfd: 05

I'm trying to use steens-aa from poolalloc on llvm-2.6. However, when I run the alias analysis, steens aa falls back on default aa because the DSNodes are incomplete. My program is very simple. The default aa identifies that &a and &c.b cannot alias but d can alias with both of them. I use the AliasAnalysis.alias method to find out pairwise from within my own analysis which of the

On 11-06-15 09:03 AM, Istvan Haller wrote: > Dear all, > I'm trying to use the gold plugin to make it easier to generate LLVM bitcode > from complex applications. I did the steps mentioned on > "http://llvm.org/docs/GoldPlugin.html". Both linking and LLVM generation seem to > work properly, however when using the tool ar, the symbol table is lost. "no > archive

On Thu, Jan 10, 2013 at 4:42 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Well, I saw the .debug_info.dwo stuff (though I didn’t realize it was so > recent), but it wasn’t clear to me how adding a map for a section with a > different purpose would work -- that is, whether it should be yet another > member variable in DWARFContextInMemory or if there was some better