similar to: distinct DISubprograms hindering sharing inlined subprogram descriptions

A few disjoint thoughts; sorry they're so delayed (I skimmed the responses below, and I think these are still relevant/not covered elsewhere). Firstly, why *should* DISubprogram definitions be distinct? There were two reasons this was valuable (this was from before there was a cu: link). - It helped to fix long-standing bugs in the IRLinker, where uniqued-DISubprograms in different compile

On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > A few disjoint thoughts; sorry they're so delayed (I skimmed the responses > below, and I think these are still relevant/not covered elsewhere). > > Firstly, why *should* DISubprogram definitions be distinct? There were > two reasons this was valuable (this was from before there

> On Dec 23, 2016, at 18:36, David Blaikie <dblaikie at gmail.com> wrote: > > > >> On Fri, Dec 23, 2016 at 11:47 AM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> A few disjoint thoughts; sorry they're so delayed (I skimmed the responses below, and I think these are still relevant/not covered elsewhere). >> >> Firstly, why

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

> On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Branching off from a discussion of improvements to DIGlobalVariable representations that Adrian's working on - got me thinking about related changes that have already been made to DISubprogram. > > To reduce duplicate debug info when things like linkonce_odr functions were

Trying to wrap my brain around this, so a few questions below. =) On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> wrote: > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have already been made to DISubprogram. > > To reduce duplicate

On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> wrote: > Trying to wrap my brain around this, so a few questions below. =) > Sure thing - sorry, did assume a bit too much arcane context here. > > On Thu, Dec 15, 2016 at 10:54 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > Branching off from a discussion of improvements to

On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> > wrote: > >> Trying to wrap my brain around this, so a few questions below. =) >> > > Sure thing - sorry, did assume a bit too much arcane context here. > > >> >> On Thu, Dec

On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> wrote: On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote: On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> wrote: Trying to wrap my brain around this, so a few questions below. =) Sure thing - sorry, did assume a bit too much arcane context here.

On Thu, Dec 15, 2016 at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> > wrote: > > On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > > > On Thu, Dec 15, 2016 at 11:26 AM Teresa Johnson <tejohnson at google.com> > wrote: >

On Thu, Dec 15, 2016 at 4:17 PM Teresa Johnson <tejohnson at google.com> wrote: > On Thu, Dec 15, 2016 at 2:08 PM, David Blaikie <dblaikie at gmail.com> wrote: > > On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com> > wrote: > > On Thu, Dec 15, 2016 at 11:38 AM, David Blaikie <dblaikie at gmail.com> > wrote: > > > > On

On Thu, Dec 15, 2016 at 4:20 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Dec 15, 2016 at 4:17 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> On Thu, Dec 15, 2016 at 2:08 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >> >> On Thu, Dec 15, 2016 at 1:30 PM Teresa Johnson <tejohnson at google.com>

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer

Hi David, OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope. But how about that we are emitting a subprogram entry that has no attributes? 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040}) DW_AT_name [DW_FORM_strp] (

Hi, I am wondering if this behavior of creating debug info is correct. A type in compile unit entry is pointing to a type under subprogram entry?! This is the root cause of https://llvm.org/bugs/show_bug.cgi?id=27579 0x0000000b: DW_TAG_compile_unit [1] * 0x00000026: DW_TAG_pointer_type [2] DW_AT_type [DW_FORM_ref4] (cu + 0x002c => {0x0000002c})

Hi, I would like to implement a fix to how LLVM handles/creates debug info for entities declared inside a basic block. Below you will find 5 parts: 1. Motivation for this fix. 2. Background explaining the cases that need to be fixed. 3. An example for each case. 4. Proposal on how to represent each case in dwarf. 5. Secondary (workaround) proposal which might be

On Mon, Dec 14, 2015 at 7:01 AM, Aboud, Amjad via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I verified that GDB 7.10 does support “DW_AT_abstract_origin” attribute on > “DW_TAG_lexical_block”. > I take it you mean that it does the right thing, finding the direct children of the abstract block when stepping into the inlined subroutine, etc? & this was a

Hi I'm using llvm-5. Browsing the source of llvm-dwarfdump and trying it on some shared libraries, I see I can print the debug info (assuming it exists). For some function, I'm wondering if there's a short cut to prettyprinting the signature of a function in the library? I think, looking at the output, that enough information exists but it seems to involve looking at the subprogram

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

Hi David, Excuse me for delayed answer. It took some time to prepare. Please, find the answers bellow... >Broad question: Do you have any specific motivation/users/etc in implementing this (if you can speak about it)? > - it might help motivate the work, understand what tradeoffs might be suitable for you/your users, etc. There are two general requirements: 1) Remove (or clean) invalid