search for: dwarfwriter

...alysis< AnalysisType >) when that same instance's getAnalysisUsage(AnalysisUsage &au) implementation invokes au.addRequired<AnalysisType>()? For example in the implementation of SelectionDAGISel::runOnMachineFunction(...) (called from MachineFunctionPass::runOnFunction(...)): DwarfWriter *DW = getAnalysisIfAvailable<DwarfWriter>(); is used vs: DwarfWriter &DW = getAnalysis<DwarfWriter>(); even though SelectionDAGISel::getAnalysisUsage(AnalysisUsage &AU) sets: AU.addRequired<DwarfWriter>(); Since this occurs in 2.6 and trunk, and this pattern is repeat...

Hi! If a pass is required then it makes sense to getAnalysis<DwarfWriter>(). getAnalysisIfAvailable<>() is used for cases where a pass want to take advantage of (or fix up) info only *if* it is available. If you prepare a patch to fix getAnalysisifAvailable<>() uses (e.g. DwarfWriter requests you mention below) then I'll apply it. - Devang On Tue,...

Hi! After commit http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060227/032167.html : - DIE *NewType(DIE *Unit, TypeDesc *TyDesc); + DIE *DwarfWriter::NewType(CompileUnit *Unit, TypeDesc *TyDesc); and http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060227/032227.html - DIE *DwarfWriter::NewType(CompileUnit *Unit, TypeDesc *TyDesc); + DIE *DwarfWriter::NewType(DIE *Context, TypeDesc *TyDesc); I can't build LLVM using gcc 4.1...

Hello The current svn revision fails to compile on windows using Visual Studio 2008. I'm getting: 3>f:\dev\llvm\lib\codegen\asmprinter\dwarfwriter.cpp(1167) : error C4716: 'llvm::DbgScope::getLine' : must return a value 3>f:\dev\llvm\lib\codegen\asmprinter\dwarfwriter.cpp(1168) : error C4716: 'llvm::DbgScope::getColumn' : must return a value 3>f:\dev\llvm\lib\codegen\asmprinter\dwarfwriter.cpp(1169) : error C4716: 'l...

...mit the debug information in assembly through assembler directives. Also I don't want to emit debug information in sections (like Dwarf). Instead the debug information will be interspersed with the assembly. However in LLVM, debug info (e.g. stoppoint) is read and made part of the DAG only when DwarfWriter is registered. How can I emit the debug information in assembly with out using DwarfWriter? Regards Sachin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090224/4fea86e9/attachment.html>

...information is placed in a separate object file section from the > debugging information > entries themselves. The value of the statement list attribute is the > offset in the > .debug_line section of the first byte of the line number information > for this compilation > unit DwarfWriter was using a label reference (instead of a section offset) and it was causing a problem because Windows treats section offsets differently, by emitting the ".secrel32" directive. -Argiris -------------- next part -------------- A non-text attachment was scrubbed... Name: dwarf-fix.patc...

...object file section from >> the debugging information >> entries themselves. The value of the statement list attribute is >> the offset in the >> .debug_line section of the first byte of the line number >> information for this compilation >> unit > > DwarfWriter was using a label reference (instead of a section > offset) and it was causing a problem because Windows treats > section offsets differently, by emitting the ".secrel32" directive. > > > -Argiris > > <dwarf-fix.patch>__________________________________________...

...n in assembly through assembler > directives. Also I don’t want to emit debug information in sections > (like Dwarf). Instead the debug information will be interspersed > with the assembly. However in LLVM, debug info (e.g. stoppoint) is > read and made part of the DAG only when DwarfWriter is registered. > > How can I emit the debug information in assembly with out using > DwarfWriter? We are moving in the direction where DwafWriter won't be required while building DAG. The work is in progress to annotate machine instructions (DebugLoc etc..) with debugging inform...

Hello > In order to avoid the set jump/long jump dependency of DLLs built under Visual C++, we're trying to build the libraries and tools under LLVM-GCC so it will use DWARF exception handling instead of SJ/LJ.  The problem we're running into is that the libraries that we just finished creating cannot be found later in the build process when OPT tries to build.  My partner has MinGW

....cpp(1273) : warning C4244: 'initializing' : conversion from 'int64_t' to 'unsigned int', possible loss of data ..\..\lib\CodeGen\AsmPrinter.cpp(1280) : warning C4244: 'initializing' : conversion from 'int64_t' to 'unsigned int', possible loss of data DwarfWriter.cpp ..\..\lib\CodeGen\DwarfWriter.cpp(383) : warning C4244: 'argument' : conversion from 'uint64_t' to 'unsigned int', possible loss of data ..\..\lib\CodeGen\DwarfWriter.cpp(1197) : warning C4244: 'argument' : conversion from 'uint64_t' to 'unsigned int&...

...mit the debug information in assembly through assembler directives. Also I don't want to emit debug information in sections (like Dwarf). Instead the debug information will be interspersed with the assembly. However in LLVM, debug info (e.g. stoppoint) is read and made part of the DAG only when DwarfWriter is registered. How can I emit the debug information in assembly with out using DwarfWriter? Regards Sachin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090224/6ce8187f/attachment.html>

...#39;s currently > failing to get the file name and path back, though it is still > correctly getting line numbers. If you happen to have a code fragment > that is known to work, it would be much appreciated. > Hi Sarah, I'm not sure if this will help you out, but take a look at how DwarfWriter::getOrCreateSourceID is used. Unfortunately, I don't see how to get the file name from a DbgStopPointInstr right offhand. Things in the CodeGen/AsmPrinter/DwarfWriter.cpp file have changed quite a bit in recent months... -bw > What it used to work was calling getFileName()->getNameStr()...

Hi folks, I had some code that used to work fine in earlier versions of LLVM, but is now failing. I have some code that expands DbgStopPointInst instructions to my own entry points in an opt pass, but it's currently failing to get the file name and path back, though it is still correctly getting line numbers. If you happen to have a code fragment that is known to work, it would be

Hello again, In order to avoid the set jump/long jump dependency of DLLs built under Visual C++, we're trying to build the libraries and tools under LLVM-GCC so it will use DWARF exception handling instead of SJ/LJ. The problem we're running into is that the libraries that we just finished creating cannot be found later in the build process when OPT tries to build. My partner has MinGW

Hello, Renato > Are you actively working in that area? No, I started to experiment with ARM EH ~year ago, but never had anything complete, unfortunately > My main concern is that DwarfException is not extensible at all. I can't inherit from it (DwarfWriter creates it directly) and there are no call backs to target-specific code (nor registration of such mechanism). Why do you need this? My feeling that this will not be required. I might be mistaken though. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersbu...

...far from being complete. Hi Anton, Are you actively working in that area? I did some experiments and managed to understand how LLVM does the exception handling, but my changes are also far from working. My main concern is that DwarfException is not extensible at all. I can't inherit from it (DwarfWriter creates it directly) and there are no call backs to target-specific code (nor registration of such mechanism). To change that in line with AsmWriter would be a major change and passing a ARMException reference through AsmWriter would pass the object through many places that are not concerned with i...

In CodeGen/DwarfWriter.cpp's EmitDebugLine file, these lines are causing havoc on Mac OS X systems: // If there are no lines to emit (such as when we're using .loc directives // to emit .debug_line information) don't emit a .debug_line header. if (SectionSourceLines.empty()) return; Basica...

...7fa91cc3a095 gsignal + 53 4 libc.so.6 0x00007fa91cc3baf0 abort + 272 5 libc.so.6 0x00007fa91cc332df __assert_fail + 239 6 llc 0x0000000000ebfdad 7 llc 0x0000000000ebffa6 8 llc 0x0000000000ec2f7b 9 llc 0x0000000000eb95e0 llvm::DwarfWriter::BeginModule(llvm::Module*, llvm::MachineModuleInfo*, llvm::raw_ostream&, llvm::AsmPrinter*, llvm::TargetAsmInfo const*) + 166 10 llc 0x0000000000b9b513 11 llc 0x0000000001142c73 llvm::FPPassManager::doInitialization(llvm::Module&) + 65 12 llc 0x...

Can we help in local variable debug info work. Dale Johannesen wrote: > On Apr 7, 2009, at 9:52 PMPDT, vasudev wrote: > > >> Thanks for the info regarding DebugLoc field. Another related >> question >> that I have is regarding debug info for local variables. With -fast >> option, ISD::DECLARE nodes are created in DAG for debug info of local >>

Hi Duncan, >>I don't get it. Sorry my bad English! hehe. >>What has this got to do with determining the >>names "@__cxa_throw" and "@_ZTi"? Record the Information into the MachineModule Info, so in Dwarfwriter or SjLjWriter(my sjlj-eh name) can build the except table correctly! 2009/3/26 Duncan Sands <baldrick at free.fr>: > Hi zhangzw, > >> >> Why do you want the names anyway? >> >> because i 'am working on llvm to support sjlj-eh for my target. >> for m...