Bram Adams
2006-Sep-25 12:24 UTC
[LLVMdev] Name of Function's original module during link-time optimization
Hi, Reid Spencer wrote:> Call getBytecodeModuleProvider (see Reader.h).The problem is that one needs to provide the filename of the original module as the argument of getBytecodeModuleProvider, whereas this is unknown (it's exactly what we're trying to find out). But, by looking where this method is called in the original bytecode loading process, I figured out a way to set the attribute I added when all Functions of a Module are linked into the sole link-time Module (see patch). The reason I pass an extra argument to so many methods (I let it default to ""), is that I'd like to have a full path name, not only the specific file name, of the original modules. As such, using someFunction->getParent()->getModuleIdentifier() in lib/Linker/LinkModules.cpp:650 did not suffice. However, I noticed that File.toString() in lib/Linker/LinkItems.cpp:150 does not yield the full path name. Could this patch (in a revised form) be added to LLVM? Kind regards, Bram Adams GH-SEL, INTEC, Ghent University (Belgium)> This will return a > ModuleProvider. Ask it for the Module and then ask the Module for its > identifier. This approach avoids loading all the functions. > > Reid. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.modulename-1.8 URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060925/2a6a42ea/attachment.ksh>
Chris Lattner
2006-Sep-25 18:07 UTC
[LLVMdev] Name of Function's original module during link-time optimization
On Mon, 25 Sep 2006, Bram Adams wrote:> Reid Spencer wrote: >> Call getBytecodeModuleProvider (see Reader.h). > The problem is that one needs to provide the filename of the original module > as the argument of getBytecodeModuleProvider, whereas this is unknown (it's > exactly what we're trying to find out). > > But, by looking where this method is called in the original bytecode loading > process, I figured out a way to set the attribute I added when all Functions > of a Module are linked into the sole link-time Module (see patch). The reason > I pass an extra argument to so many methods (I let it default to ""), is that > I'd like to have a full path name, not only the specific file name, of the > original modules. As such, using > someFunction->getParent()->getModuleIdentifier() in > lib/Linker/LinkModules.cpp:650 did not suffice. However, I noticed that > File.toString() in lib/Linker/LinkItems.cpp:150 does not yield the full path > name. > > Could this patch (in a revised form) be added to LLVM?What are you trying to accomplish? Why not use location records from debug info? -Chris -- http://nondot.org/sabre/ http://llvm.org/
Bram Adams
2006-Sep-25 20:13 UTC
[LLVMdev] Name of Function's original module during link-time optimization
Hi, Op 25-sep-06, om 20:07 heeft Chris Lattner het volgende geschreven:> What are you trying to accomplish? Why not use location records from > debug info?You mean the debugging intrinsics? Just discovered them :-), and I guess that's exactly what I need. Haven't tried them extensively yet, so I'm wondering whether the remark in your mail of 09/04/2006 to Nikhil Patil about "-g currently disables many optimizations" still holds. Kind regards, Bram Adams -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060925/7031ba01/attachment.html>
Possibly Parallel Threads
- [LLVMdev] Name of Function's original module during link-time optimization
- [LLVMdev] Name of Function's original module during link-time optimization
- [LLVMdev] Name of Function's original module during link-time optimization
- [LLVMdev] Name of Function's original module during link-time optimization
- [LLVMdev] Name of Function's original module during link-time optimization