similar to: [LLVMdev] Moving to LLVM 3.2 metadata format for DWARF generation

Hi all, I'm using LLVM 2.9 metadata format for DWARF generation in my .ll file. I would like to know if there is any benefit moving to LLVM 3.2 format ? Thanks for your answers Best Regards Seb

The old format is going away as soon as I (or someone else) can update dragonegg. Also, no real effort is being made in making sure that anything works in the old format. -eric On Thu, Jan 17, 2013 at 5:56 AM, Sebastien DELDON-GNB < sebastien.deldon at st.com> wrote: > Hi all, > > I'm using LLVM 2.9 metadata format for DWARF generation in my .ll file. > I would like to

Usually the array ordering is implied by the language; for example LLVM supports Fortran via Dragonegg but we still don't set the ordering explicitly, we rely on the debugger to assume the right ordering because of the language code. You wouldn't need to set ordering unless you want an ordering that isn't the language default, or you're using a language code that the debugger

Not at the moment, we've been adding things that need additions to the metadata on an "as needed" basis. Do you have a language that allows you to swap orderings in source code? If so, then feel free to add it to the array type metadata and send a patch. -eric On Oct 3, 2013 1:15 PM, "sebastien deldon (PGI)" < sebastien.deldon at pgroup.com> wrote: > Hi all,****

Hi all, Is there a way to set up array ordering (DW_ORD_row_major or DW_ORD_col_major) using debug metadata ? Best Regards Seb ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited.

Hi all, What is retained type list designed for in debug metadata ? Thanks for your answer Seb ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended

It's designed to deal with types that may not be referenced via other metadata. Anonymous metadata not referenced by named metadata will be automatically removed. -eric On Mon, Sep 16, 2013 at 4:18 AM, sebastien deldon (PGI) <sebastien.deldon at pgroup.com> wrote: > Hi all, > > > > What is retained type list designed for in debug metadata ? > > > > Thanks for

Hi all, I would like to know how can I express debug information for an outlined function using llvm debug metadata. I mean I have a function f() and part of its code is outlined in a new function g() . I would like to generate llvm debug metadata so that when stepping in g() the debugger step in original sources lines from f() routine ? Thanks for your help Seb

----- Original Message ----- > From: "David Blaikie" <dblaikie at gmail.com> > To: "sebastien deldon (PGI)" <sebastien.deldon at pgroup.com>, "Eric Christopher" <echristo at gmail.com> > Cc: "llvmdev" <llvmdev at cs.uiuc.edu> > Sent: Monday, January 27, 2014 10:12:27 AM > Subject: Re: [LLVMdev] Debug information for

Hi all, I'm using my own front-end that generates LLVM debug info metadata. I was using LLVM 2.9 debug version and I'm moving to LLVM 3.2 debug version of metadata. On my example I got llc 3.2 to fail on following assertion: llc: /work1/tools/llvm/3.2/sources/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1471: void llvm::DwarfDebug::endFunction(const llvm::MachineFunction*): Assertion `TheCU

Yes I agree with David, I don't think we can draw analogy between lambda and outlined routines. Seb From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Monday, January 27, 2014 5:51 PM To: Hal Finkel Cc: llvmdev; sebastien deldon (PGI); Eric Christopher Subject: Re: [LLVMdev] Debug information for outlined routine > Given that LLVM has no current support for outlining I don't

Hi Devang, Not only "vtable ptr" is a problem, for this field it seems that CLANG emits a NULL metadata node which is translated into 'i32 0'. The other problem is for 'isArtificial' field with is described as being of type i1 and CLANG emits i32. Looking at sources, it seems that it should be a i32 flag field. Hope this helps, Best Regards Seb 2011/12/15 Devang

On Thu, Feb 7, 2013 at 3:12 AM, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > Hi all, > > I'm using my own front-end that generates LLVM debug info metadata. I was using LLVM 2.9 debug version and I'm moving to LLVM 3.2 debug version of metadata. If at all possible please migrate to using the DIBuilder interface. I'm trying to port DragonEgg over to

Hi Eric, On 17/01/13 20:15, Eric Christopher wrote: > The old format is going away as soon as I (or someone else) can update > dragonegg. Also, no real effort is being made in making sure that anything works > in the old format. I've marked converting the debug stuff as a high priority in my TODO list. But this doesn't really mean anything :) Ciao, Duncan.

On Dec 15, 2011, at 2:32 AM, Seb wrote: > Hi all, > > In LLVM documentation about source level debugging (http://www.llvm.org/releases/2.9/docs/SourceLevelDebugging.html) > > > Subprogram descriptor is defined as: > > !2 = metadata !{ > i32, ;; Tag = 46 + LLVMDebugVersion > ;; (DW_TAG_subprogram) > > i32, ;; Unused field. >

Hi all, In LLVM documentation about source level debugging (http://www.llvm.org/releases/2.9/docs/SourceLevelDebugging.html) Subprogram descriptor is defined as: !2 = metadata !{ i32, ;; Tag = 46 + LLVMDebugVersion <http://www.llvm.org/releases/2.9/docs/SourceLevelDebugging.html#LLVMDebugVersion> ;; (DW_TAG_subprogram) i32, ;; Unused field. metadata, ;;

Hi Renato, You're right it's VMLA/VMLS that are generated. Still don't understand what drives generation for Cortex-A9. I was using fmac for floating point MAC not for fused MAC. Than I realized that we spoke about fma instead of fmac. So back to the original problem why when using -mcpu=cortex-a9 VMLA/VMLS are not generated and when I use -mtriple=armv7-eabi they are ? Best

Hi all, I'm generating code using CLANG + LLVM 2.9 and would like to inspect formal parameter value for x86 32-bit when -O2 -g is used. It seems that when code is optimized by the compiler DWARF information generated doesn't allow to inspect value of parameter. Trying to inspect parameter value in GDB, parameter is marked as optimized by the compiler and thus I can't track its value.

cat /proc/cpuinfo ? Are you sure it's generating VFMA and not VMLA? On Fri, Nov 9, 2012 at 9:35 AM, Sebastien DELDON-GNB < sebastien.deldon at st.com> wrote: > Hi Renato, > > It's definitively not A15. Can this be the case that NEON units for > cortex-A9 support it but isn't documented/recommended ? > And as mentioned before code is working ! > > Seb >

Hi Renato, It's definitively not A15. Can this be the case that NEON units for cortex-A9 support it but isn't documented/recommended ? And as mentioned before code is working ! Seb > -----Original Message----- > From: rengolin at gmail.com [mailto:rengolin at gmail.com] On Behalf Of > Renato Golin > Sent: Friday, November 09, 2012 6:27 PM > To: Sebastien DELDON-GNB >