similar to: [LLVMdev] help converting llvm metadata into dwarf tags

Hi Roger, On Mon, Aug 23, 2010 at 4:01 PM, Roger Wang <innit42 at gmail.com> wrote: > Dear all, > > I'd like to find the memory location of certain instructions in a > compiled/linked binary. During the IR phase, I tag instructions I'm > interested in with LLVM'-2.7's new metadata (MDNodes with an identifiable > ID). I'd now like to propagate that data

hi Devang and thanks for the tips, i finally managed to fit all the pieces together into something that seems to work. It's probably not the best (or even correct!) way of doing it but here's a brief overview for reference: An instruction in the LLVM IR gets converted into an SDNode in the DAG then later into a MachineInstr. I'd already attached my own MDNodes to IR instructions I

Might be easier if these were on Phabricator, but here are some thoughts: 0001: This patch generally, while separated for legibility, is untested & difficult to discuss in isolation. I may need to refer to the second patch in reviewing this first one. DwarfDebug.cpp: computeSizeAndOffsets: I believe this produces the wrong offset for the 3rd CU and onwards. computeSizeAndOffset

On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote: > Your recent changes mentioned below would change correctness of debug info, > but it would unlikely to impact structure of DWARF generated. And somehow, > this structure is invalid in your case. I was hoping for a quick-fix on the assumptions of DwarfDebug about Subprograms' MDNodes, but it might be

On Wed, Oct 9, 2013 at 1:32 PM, Manman Ren <manman.ren at gmail.com> wrote: > > David, > > Thanks for reviewing! > > On Wed, Oct 9, 2013 at 11:36 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> Might be easier if these were on Phabricator, but here are some thoughts: >> >> 0001: >> This patch generally, while separated for

Hi All, The first patch adds support for ref_addr. Most of it is from r176882, but instead of always using an integer for ref_addr, we use label + offset for relocation on non-darwin platforms. The second patch is a modified version of r191792. The main change is to use a single map instead of 3 maps in DwarfDebug and instead of calling DwarfDebug::getDIE|insertDIE directly, we delegate the

Ping -Manman On Fri, Oct 4, 2013 at 7:00 PM, Manman Ren <manman.ren at gmail.com> wrote: > > Hi All, > > The first patch adds support for ref_addr. > Most of it is from r176882, but instead of always using an integer for > ref_addr, we use label + offset for relocation on non-darwin platforms. > > The second patch is a modified version of r191792. > The main

On Thu, Jun 20, 2013 at 5:25 PM, Manman Ren <mren at apple.com> wrote: > > On Jun 20, 2013, at 5:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > On Thu, Jun 20, 2013 at 5:13 PM, Manman Ren <mren at apple.com> wrote: > > > On Jun 20, 2013, at 4:52 PM, David Blaikie wrote: > > On Thu, Jun 20, 2013 at 4:45 PM, Manman Ren <mren at apple.com>

BTW, the reason I stopped responding to this thread is not because I solved the problem, but because I simply gave up and decided to work on other things for a while since I was making no progress. Having finished those other things (the stack crawler, for one), I'm hoping that time and a fresh start will yield better results. Unfortunately after about a day spent reviewing old llvm-dev

On Thu, Jun 20, 2013 at 4:45 PM, Manman Ren <mren at apple.com> wrote: > > On Jun 20, 2013, at 3:55 PM, Manman Ren <mren at apple.com> wrote: > > > On Jun 20, 2013, at 2:58 PM, Eric Christopher wrote: > > Hi Manman, > > On Thu, Jun 20, 2013 at 2:51 PM, Manman Ren <mren at apple.com> wrote: > > > The intent of this proposal is to speedup

On Fri, Jun 21, 2013 at 11:50 AM, Manman Ren <mren at apple.com> wrote: > > On Jun 21, 2013, at 11:35 AM, Eric Christopher wrote: > >> On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at apple.com> wrote: >>> >>> A summary of options for issue #3: >>> 3> To actually access the MDNode referenced via the hash value, we need to perform a

On Fri, Jun 21, 2013 at 12:33 PM, Manman Ren <mren at apple.com> wrote: > > On Jun 21, 2013, at 11:56 AM, Eric Christopher wrote: > >> On Fri, Jun 21, 2013 at 11:50 AM, Manman Ren <mren at apple.com> wrote: >>> >>> On Jun 21, 2013, at 11:35 AM, Eric Christopher wrote: >>> >>>> On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at

On Jun 20, 2013, at 2:58 PM, Eric Christopher wrote: > Hi Manman, > > On Thu, Jun 20, 2013 at 2:51 PM, Manman Ren <mren at apple.com> wrote: >> >> The intent of this proposal is to speedup compilation of "-flto -g" for c++ programs. >> This is based on discussions with Adrian, David and Eric. >> > > Thanks for bringing this back to the

On Thu, Jun 20, 2013 at 5:13 PM, Manman Ren <mren at apple.com> wrote: > > On Jun 20, 2013, at 4:52 PM, David Blaikie wrote: > >> On Thu, Jun 20, 2013 at 4:45 PM, Manman Ren <mren at apple.com> wrote: >>> >>> On Jun 20, 2013, at 3:55 PM, Manman Ren <mren at apple.com> wrote: >>> >>> >>> On Jun 20, 2013, at 2:58 PM, Eric

The first patch seems fine, though the comment on the modified addDIEEntry function is a bit confusing: -/// addDIEEntry - Add a DIE attribute data and value. +/// addDIEEntry - Add a DIE attribute data and value. The form should be +/// a reference form: ref1, ref2, ref4, ref8, ref_udata, ref_addr, +/// or ref_sig8. A form can be chosen inside addDIEEntry. When the comment says "The form

The intent of this proposal is to speedup compilation of "-flto -g" for c++ programs. This is based on discussions with Adrian, David and Eric. --------------------------- Problem: A single class can be used in multiple source files and the DI (Debug Info) class is included in multiple bc files. The duplication of class definitions causes blow-up in # of MDNodes, # of DIEs, leading to

On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at apple.com> wrote: > > A summary of options for issue #3: > 3> To actually access the MDNode referenced via the hash value, we need to perform a lookup from the hash value to find the corresponding MDNode. > The questions are where to store this map and how to keep it up-to-date when a MDNode is replaced. >

On Jun 21, 2013, at 11:56 AM, Eric Christopher wrote: > On Fri, Jun 21, 2013 at 11:50 AM, Manman Ren <mren at apple.com> wrote: >> >> On Jun 21, 2013, at 11:35 AM, Eric Christopher wrote: >> >>> On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at apple.com> wrote: >>>> >>>> A summary of options for issue #3: >>>>

It seems to me that emitting DWARF line number information using .loc directives is currently broken. CellSPU is currently the only in tree target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it to produce any line number information. Is this a known issue? I understand that there are lots of changes going on in this area. Any idea what it would take to fix? -- Richard

On Sep 7, 2010, at 9:11 AM, Renato Golin wrote: > On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote: >> Your recent changes mentioned below would change correctness of debug info, >> but it would unlikely to impact structure of DWARF generated. And somehow, >> this structure is invalid in your case. > > I was hoping for a quick-fix on the