similar to: [LLVMdev] Dwarf Accelerator Tables

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

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:

On Tue, Aug 8, 2017 at 10:50 AM Robinson, Paul <paul.robinson at sony.com> wrote: > Can gdb handle these? i.e. is it just gold that has the problem? > Yep, it's just gold when it's building the gdb-index (an accelerator table for GDB) > Conditioning on debugger tuning when it's not the debugger that has the > problem… icky. > It does. Though to a lesser

I am looking to create a tool that can add Apple or DWARF5 accelerator tables to fully linked executables that contain DWARF. This will help us benchmark how much accelerator tables can improve the debugging experience as debuggers don't need to manually index all of the debug info during debugging. Looking at how accelerator tables are currently emitted, they seem to be built up as DWARF is

Which seems like what we'd want dsymutil to do anyhow? -eric On Mon, Mar 2, 2020 at 3:21 PM Greg Clayton via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On other options would be to make a new "llvm-dwarfld" tool, where most of > the functionality would exist llvm/lib/DwarfLinker and other locations. The > idea would be to do any post processing to DWARF using

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

On Mar 8, 2012, at 2:29 PM, Pranav Bhandarkar wrote: > Hi All, > > I just enabled the generation of dwarf debugging information for Hexagon. It > did not require much save for the setting of a flag in MCAsmInfo. > > However, now I see that the ".debug_pubnames" sections is not generated. I > did read discussion about the section not really being useful for

> On Feb 28, 2020, at 11:25 PM, Fangrui Song via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 2020-02-28, Greg Clayton via llvm-dev wrote: >> I am looking to create a tool that can add Apple or DWARF5 accelerator tables to fully linked executables that contain DWARF. This will help us benchmark how much accelerator tables can improve the debugging experience as

Adrian: any thoughts? Has LLDB been fixed to support this yet? On Tue, Aug 8, 2017 at 6:33 AM Robinson, Paul <paul.robinson at sony.com> wrote: > My inclination would be to use "disable if 32-bit and –ggnu-pubnames" as > the default, > Unfortunately Nico points out that Chrome doesn't currently use -ggnu-pubnames :/ So to continue to work "out of the box"

We have customers that rely on the symbol information from the "pubnames" section in the DWARF data. Generation of this information was removed in this commit: commit dfa30e1ab243990eda4732a6dffb91e965e7a755 Author: Eric Christopher <echristo at apple.com> Date: Wed Nov 9 05:24:07 2011 +0000 Remove the pubnames section, no one consumes it. git-svn-id:

>We have customers that rely on the symbol information from the >"pubnames" section in the DWARF data. Generation of this information >was removed in this commit: > >commit dfa30e1ab243990eda4732a6dffb91e965e7a755 >Author: Eric Christopher <echristo at apple.com> >Date: Wed Nov 9 05:24:07 2011 +0000 > > Remove the pubnames section, no one consumes

Is there/could you further explain the use-case for adding an index to an existing binary? Certainly not the worst idea/could come in handy sometimes, but you mention benchmarking - is the benefit of not recompiling/relinking that significant to such experiments? If it's not for use in a common workflow, but only in a compiler/debugger development workflow, it doesn't seem so important to

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

On Fri, Jan 11, 2013 at 1:49 PM, Robinson, Paul <Paul.Robinson at am.sony.com>wrote: > >We have customers that rely on the symbol information from the > >"pubnames" section in the DWARF data. Generation of this information > >was removed in this commit: > > > >commit dfa30e1ab243990eda4732a6dffb91e965e7a755 > >Author: Eric Christopher

I'd like it... Adrian? Fred? -eric On Mon, Mar 2, 2020 at 3:44 PM Greg Clayton <clayborg at gmail.com> wrote: > Yes. I am fine with adding ELF support to llvm-dsymutil if that is the way > people think we should go? > > On Mar 2, 2020, at 3:33 PM, Eric Christopher <echristo at gmail.com> wrote: > > Which seems like what we'd want dsymutil to do anyhow? >

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

On Tue, Aug 8, 2017 at 6:56 AM Nico Weber <thakis at chromium.org> wrote: > On Aug 7, 2017 6:58 PM, "David Blaikie" <dblaikie at gmail.com> wrote: > > Context: > > In r309526 (with a followup fix in r309529) I implemented the use of > DWARF's debug_ranges base address specifier entries to reduce the number of > object file relocations needed for

> On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As mentioned by Adrian in the comment you linked, I too am looking at DWARFv5 > accelerator tables in LLVM. > > To give you some background: my motivation is that I want to upstream support > for (Apple style) accelerator tables in llvm-dsymutil, Some background for

On 01.09.2020 06:27, David Blaikie wrote: > A quick note: The feature as currently proposed sounds like it's an > exact match for 'dwz'? Is there any benefit to this over the existing > dwz project? Is it different in some ways I'm not aware of? (I haven't > actually used dwz, so I might have some mistaken ideas about how it > should work) > > If

Thank you for all the responses. Unfortunately I wasn't able to make any progress on creating the patches today. I'll be sure to add everyone who expressed interest here to the phabricator diff once I have them ready. Jonas, do you have any dsymutil patches I can look at? I am interested in seeing what kind of interfaces are you using, particularly on the reading side. I think the current