similar to: [LLVMdev] What does "debugger tuning" mean?

Another example would be .debug_pubnames and .debug_pubtypes sections. Currently these default to omitted for Darwin and PS4, but included everywhere else. My initial patch for "tuning" changes the PS4 platform criterion to the SCE debugger predicate; quite likely the "not Darwin" criterion ought to be "not LLDB" or in other words "on for GDB only."

> A few more things that vote for debugger tuning: > > - LLDB doesn't like to have DWARF that has a class A that inherits from > class B, but only a forward declaration of class B is provided. Hmm do we emit that kind of thing today? In a naïve test, I'm seeing the full description of class B. > - LLDB wants the .apple_XXX accelerator tables, GDB wants >

> On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com> wrote: > > >> On May 1, 2015, at 2:00 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: >> >>> A few more things that vote for debugger tuning: >>> >>> - LLDB doesn't like to have DWARF that has a class A that inherits from >>> class B, but

> On May 5, 2015, at 8:12 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > > > On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com <mailto:gclayton at apple.com>> wrote: > > > > > >> On May 1,

I just skimmed through the thread again, and I *think* all the main questions have been answered… It feels like the consensus is "reluctant agreement," with the specific design points being: - a "debugger tuning" option would have some sort of target-based default - the "debugger tuning" option would unpack into defaults for individual feature flags -

I don’t think there was a driver patch so far, was there? -- adrian > On May 6, 2015, at 1:19 PM, Eric Christopher <echristo at gmail.com> wrote: > > Does the patch do all of this? > > -eric > > On Wed, May 6, 2015 at 1:18 PM Robinson, Paul <Paul_Robinson at playstation.sony.com <mailto:Paul_Robinson at playstation.sony.com>> wrote: > I just skimmed

Comments on the patch raise the following questions, probably better discussed here. First: Should LLVM default to "no tuning" rather than a target-specific default? There are two natural follow-up questions: What would "no tuning" actually mean? Where would the target-specific defaulting occur? I originally came down against the "no tuning" option, in favor of the

In some cases we do want to make the decision based on the target. For Hexagon, we don't support GDB anymore, only LLDB, so we always want LLDB tuning. The clang driver should have a way to specify that. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -----Original Message----- From:

> -----Original Message----- > From: Daniel Berlin [mailto:dberlin at dberlin.org] > Sent: Friday, May 01, 2015 3:15 PM > To: Robinson, Paul > Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers > Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu > Subject: Re: [LLVMdev] What does "debugger tuning" mean? > > On Fri, May

While I've already posted reviews for the initial patches for this (see http://reviews.llvm.org/D8506 and http://reviews.llvm.org/D8599), the grapevine suggests I should post a lengthier description of my intent for the "debugger target." The idea was prompted by a suggestion from Eric Christopher, and I'm running with it. Various bits of the DWARF we produce are conditional on

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.

Hello all, I am implementing support for .debug_names section (which is introduced in DWARFv5 standard as replacement for .debug_pubnames and .debug_pubtypes). The question is: should usage of DWARF version 5 force generation of .debug_names instead of .debug_pubnames or we can make it just default behavior and provide user with the interface (cmd switch) to use other DWARFv5 features but

Hello again, It's been nearly six months since my first email, so it's a good time to recap what has been done here so far. I am happy to report that stages 1-3 (i.e. producer/consumer in llvm and integration with lldb) of my original plan are now complete with one caveat. The caveat is that the .debug_names section is presently not a full drop-in replacement for the .apple_*** sections.

> On Jun 13, 2018, at 11:18 AM, Jonas Devlieghere via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > Hi Pavel, > >> On Jun 13, 2018, at 6:56 AM, Pavel Labath <labath at google.com <mailto:labath at google.com>> wrote: >> >> Hello again, >> >> It's been nearly six months since my first email, so it's a good time >> to

> On Jun 14, 2018, at 7:01 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thank you all. I am going to try to reply to all comments in a single email. > > Regarding the .apple_objc idea, I am afraid the situation is not as > simple as just flipping a switch. Jonas is currently working on adding the support for DWARF5-style Objective-C accelerator

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

Sorry, this is the attachment. 2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>: > Thank you. > > Here is an example and the attchment contains extra files including object > file and executable file. > I want to print for example the value of "a", but lldb command "frame > variable a" displays "0" and so does "b", and

On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: > so I'm writing this email to see if there's anyone > else interested in this topic, and to try to synchronize our efforts. I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer for GDB (but not producing/using DW_IDX_DIE_offset as GDB cannot use it). > 1. add .debug_names support to

On Mon, Mar 16, 2020 at 10:50 AM Robinson, Paul <paul.robinson at sony.com> wrote: > SCE tuning does turn on the .debug_aranges section. Our debugger team > really cares about startup cost. Turnaround time in general is huge for our > licensees, to the point where we support edit-and-continue (minimal > rebuild, live-patch the running process). > Ah, good to know! I'd

On 26.08.2020 10:58, James Henderson wrote: > In principle, this sounds reasonable to me. I don't know enough about > dsymutil's interface to know whether it makes sense to try to make it > multi-format compatible or not. If it doesn't I'm perfectly happy for > a new tool to be added using the DWARFLinker library. > > Some more general thoughts: > 1)