search for: issubprogram

Hi Chen, On Jul 8, 2011, at 11:56 AM, kobe James wrote: > Hi All, > > I hope to get some information about functions in a bitcode file. Say, if we have a function foo(), and the bitcode file is generated by a single source file, then I want to get the line number foo() locates in that source file. > If the bitcode file is linked by multiple bitcode files, is it possible to also get

...all possible MD Nodes. > > I'm not sure if that's the right answer. > > In any case this problem should only apply to assembly printing - it > doesn't explain why other parts of the codebase need to use Verify at > all. Totally agree. We should just be able to use isSubprogram in the following example. --- tools/opt/opt.cpp (revision 183537) +++ tools/opt/opt.cpp (working copy) @@ -389,7 +389,7 @@ for (unsigned i = 0, e = NMD->getNumOperands(); i != e; ++i) { std::string Name; DISubprogram SP(NMD->getOperand(i)); - if (SP.Verify...

Hi All, I hope to get some information about functions in a bitcode file. Say, if we have a function foo(), and the bitcode file is generated by a single source file, then I want to get the line number foo() locates in that source file. If the bitcode file is linked by multiple bitcode files, is it possible to also get which file foo() locates in? Thanks, Chen -------------- next part

...nvolved? What's it meant to test? What's it actually testing? DIE.h: checkCompileUnit could probably be called "getCompileUnitOrNull", the name "check*" seems to imply that it does some checking, which isn't true. DwarfCompileUnit.cpp: the "istype || issubprogram" check should probably be pulled out into a separate function, something like "isShareableAcrossCUs" or something like that (please, that's not the best name, let's discuss it further before we settle on a name) so that getDIE and insertDIE are sure to use the same test at al...

...mpileUnit could probably be called "getCompileUnitOrNull", the >> name "check*" seems to imply that it does some checking, which isn't true. >> > Will do. > Done in attached patch. > > >> DwarfCompileUnit.cpp: >> the "istype || issubprogram" check should probably be pulled out into >> a separate function, something like "isShareableAcrossCUs" or something >> like that (please, that's not the best name, let's discuss it further >> before we settle on a name) so that getDIE and insertDIE are sure...

...t;check*" seems to imply that it does some checking, which isn't >>>> true. >>>> >>> Will do. >>> >> Done in attached patch. >> >>> >>> >>>> DwarfCompileUnit.cpp: >>>> the "istype || issubprogram" check should probably be pulled out >>>> into a separate function, something like "isShareableAcrossCUs" or >>>> something like that (please, that's not the best name, let's discuss it >>>> further before we settle on a name) so that getDI...

...gle DIE and uses ref_addr". DIE.h: > checkCompileUnit could probably be called "getCompileUnitOrNull", the > name "check*" seems to imply that it does some checking, which isn't true. > Will do. > DwarfCompileUnit.cpp: > the "istype || issubprogram" check should probably be pulled out into > a separate function, something like "isShareableAcrossCUs" or something > like that (please, that's not the best name, let's discuss it further > before we settle on a name) so that getDIE and insertDIE are sure to use >...

...OrNull", >>> the name "check*" seems to imply that it does some checking, which isn't >>> true. >>> >> Will do. >> > Done in attached patch. > >> >> >>> DwarfCompileUnit.cpp: >>> the "istype || issubprogram" check should probably be pulled out >>> into a separate function, something like "isShareableAcrossCUs" or >>> something like that (please, that's not the best name, let's discuss it >>> further before we settle on a name) so that getDIE and insert...

On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > I've carefully studied the source code of CGDebugInfo in clang as a working > example. One puzzlement is that there's a discrepancy between what the > "source level debugging with LLVM" docs say and what clang does: According > to the docs, DW_TAG_formal_parameter is used to specify a formal

...t;>>>> true. >>>>>> >>>>> Will do. >>>>> >>>> Done in attached patch. >>>> >>>>> >>>>> >>>>>> DwarfCompileUnit.cpp: >>>>>> the "istype || issubprogram" check should probably be pulled out >>>>>> into a separate function, something like "isShareableAcrossCUs" or >>>>>> something like that (please, that's not the best name, let's discuss it >>>>>> further before we settle...

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

...es some checking, which isn't >>>>> true. >>>>> >>>> Will do. >>>> >>> Done in attached patch. >>> >>>> >>>> >>>>> DwarfCompileUnit.cpp: >>>>> the "istype || issubprogram" check should probably be pulled out >>>>> into a separate function, something like "isShareableAcrossCUs" or >>>>> something like that (please, that's not the best name, let's discuss it >>>>> further before we settle on a name) s...

...t;check*" seems to imply that it does some checking, which isn't >>>> true. >>>> >>> Will do. >>> >> Done in attached patch. >> >>> >>> >>>> DwarfCompileUnit.cpp: >>>> the "istype || issubprogram" check should probably be pulled out >>>> into a separate function, something like "isShareableAcrossCUs" or >>>> something like that (please, that's not the best name, let's discuss it >>>> further before we settle on a name) so that getDI...

...OrNull", >>> the name "check*" seems to imply that it does some checking, which isn't >>> true. >>> >> Will do. >> > Done in attached patch. > >> >> >>> DwarfCompileUnit.cpp: >>> the "istype || issubprogram" check should probably be pulled out >>> into a separate function, something like "isShareableAcrossCUs" or >>> something like that (please, that's not the best name, let's discuss it >>> further before we settle on a name) so that getDIE and insert...

...ntly looks like (note that some parts are commented out for debugging purposes): DISubprogram CodeGenerator::genDISubprogram(const FunctionDefn * fn, Function * f) { DASSERT(fn != NULL); // Look up in the map to see if already generated. DISubprogram & sp = dbgSubprograms_[fn]; if (!sp.isSubprogram()) { DIType dbgFuncType = genDIType(fn->functionType()); DASSERT(dbgFuncType.Verify()); DASSERT(dbgCompileUnit_.Verify()); sp = dbgFactory_.CreateSubprogram( dbgCompileUnit_, fn->name(), fn->qualifiedName(), fn->linkageName(), dbgF...

...;>>>> >>>>>> Will do. >>>>>> >>>>> Done in attached patch. >>>>> >>>>>> >>>>>> >>>>>>> DwarfCompileUnit.cpp: >>>>>>> the "istype || issubprogram" check should probably be pulled out >>>>>>> into a separate function, something like "isShareableAcrossCUs" or >>>>>>> something like that (please, that's not the best name, let's discuss it >>>>>>> further befor...

...gt;>> Will do. >>>>>> >>>>>> Done in attached patch. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> DwarfCompileUnit.cpp: >>>>>>>> the "istype || issubprogram" check should probably be pulled out >>>>>>>> into a separate function, something like "isShareableAcrossCUs" or something >>>>>>>> like that (please, that's not the best name, let's discuss it further before >>>>&gt...

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

...;>>>> >>>>>> Will do. >>>>>> >>>>> Done in attached patch. >>>>> >>>>>> >>>>>> >>>>>>> DwarfCompileUnit.cpp: >>>>>>> the "istype || issubprogram" check should probably be pulled out >>>>>>> into a separate function, something like "isShareableAcrossCUs" or >>>>>>> something like that (please, that's not the best name, let's discuss it >>>>>>> further befor...

This isn't a realistic/viable implementation, just a hacked up "can I make it produce the right output" kind of thing, but while I hammer out a few more details (like fixing MC to allow multiple sections with the same name but different comdat groups) I figured I'd throw it out there to have a bit of a chat about it. I've tested simple cases of a single type and they seem to