similar to: [LLVMdev] debugloc metadata variation

(sorry for the duplicate Fred, I failed at reply-all the first time) On Wed, Oct 22, 2014 at 6:33 PM, Frédéric Riss <friss at apple.com> wrote: > > > On Oct 22, 2014, at 4:57 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Just working on some of the gmlt+fission debug info stuff and I came > across a comment that might be relevant to reducing the

On Thu, Aug 28, 2014 at 11:51 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > This sounds great. Teaching backend about the -gmlt might help us in > another way: we might enforce full debug info generation in the frontend > for -fsanitize= flags, then rely on some parts of this debug info in > instrumentation passes and prune it before the actual object file >

So, after many shenanigans, we finally have -gmlt-like inline summary debug info in .debug_info when using -gsplit-dwarf (see r221306). Hooray \o/ Testing this with asan, it seems to be working: Given a simple example of inlining failure: $ cat asan.cpp __attribute__((always_inline)) inline void func(int* i) { *i = 3; } int main() { func(nullptr); } The failures before this change: #0

In an effort to fix inlined information for backtraces under DWARF Fission in the absence of the split DWARF (.dwo) files, I'm planning on adding -gmlt-like data to the .o file, alongside the skeleton CU. Since that will involve teaching the LLVM about -gmlt (moreso than it already has - the debug info LLVM metadata already describes -gmlt for the purposes of omitting pubnames in that case) I

On Sun, Oct 26, 2014 at 7:23 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > The fundamental questions we need to answer are the following: > FWIW, there was a longer discussion on the lists when the actual option was added. I'll try to relay my memory of that discussion, but you might need to track it down or involve some of the other people who participated in it.

>> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On >> Behalf Of Saman Aliari Zonouz >> Sent: Thursday, July 09, 2009 11:44 AM >> To: llvmdev at cs.uiuc.edu >> Subject: [LLVMdev] Source file information. >> >> Hi, >> >> I am new to LLVM, and need to find the line number

On 2009-07-09 11:17, Aaron Gray wrote: >>> -----Original Message----- >>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >>> >> On >> >>> Behalf Of Saman Aliari Zonouz >>> Sent: Thursday, July 09, 2009 11:44 AM >>> To: llvmdev at cs.uiuc.edu >>> Subject: [LLVMdev] Source file

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"

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 debug_ranges*. * in a particular binary internally, an optimized build had a 70% reduction in debug_ranges.reloc, a 16% decrease in total object size (with compressed debug info and fission) Nico noted

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

All software development progresses so quickly that anyone's script may not be current. Even a script I may have written. And that is the overall challenge with scripts, in general. We users become dependent on scripts. And we users need the learn independence. I have been learning what scripts do and how scripts do what they do. I was wanting to install 4.3.1 on Debian8 and see if I

On Fri, Oct 24, 2014 at 4:06 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Diego, > > I think sampleFDO needs to be designed in a way which can protect itself > from future breakage like this. The roots in the unnecessary dependency of > sample FDO on gmlt setting. It is totally reasonable to tune debug binary > size by changes like this. > > The right way

I've got a suggestion for a refinement: Right now, we have classes like DILocation that wrap an MDNode* to provide more convenient access to it. It would be more convenient for users if instead of MDNode *DbgInfo = Inst->getMD(MDKind::DbgTag); Inst2->setMD(MDKind::DbgTag, DbgInfo); they could write: DILocation DbgInfo = Inst->getMD<DILocation>();

There is already –mllvm –use-unknown-locations which ought to trigger this. Don't need my patch. --paulr From: Kostya Serebryany [mailto:kcc at google.com] Sent: Thursday, December 01, 2016 4:08 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Libfuzzer depending on uninitialized debug info On Thu, Dec 1, 2016 at 3:37 PM, Robinson, Paul <paul.robinson at

I'm not sure if this was intended, but it's going to be a problem for sample profiles. When we compile with -gmlt, the profiler expects to find the line number for all the function headers so that it can compute relative line locations for the profile. The tool that reads the ELF binary is not finding them, so it writes out absolute line numbers, which are impossible to match during the

Devang's work on debug info prompted this, thoughts welcome: http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt -Chris

On Fri Oct 24 2014 at 6:21:14 PM David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Oct 24, 2014 at 3:16 PM, Diego Novillo <dnovillo at google.com> > wrote: > >> >> >> On Fri Oct 24 2014 at 6:11:21 PM David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> On Fri, Oct 24, 2014 at 2:48 PM, Diego Novillo <dnovillo at

On 10/30/13 7:09 PM, Philip Reames wrote: > David, Quentin - Thanks for the feedback. Responses inline. > > On 10/30/13 11:21 AM, David Blaikie wrote: >> Actually CCing Eric. >> >> >> On Wed, Oct 30, 2013 at 11:00 AM, Quentin Colombet >> <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Philip, >>

Dear All, To add to this, what you want to do is find the appropriate debug stop point intrinsic and then use it to look up the information for that instruction. Here is some sample code from SAFECode that finds the debug information associated with a CallInst (LLVM call instruction) held in the variable CI. It uses the findStopPoint() function in llvm/Analyis/DebugInfo.h: // // Get the

Hmmm that is a funny sequence. I know the .cfi directives are represented as pseudo-instructions, but they should not be causing us to emit .loc directives. They have no effect on the .text section so probably they should just be excluded from emitting a location, same as DBG_VALUE is excluded. Also I believe the label there is unnecessary, but that's a separate issue. Regarding "how