similar to: [LLVMdev] debug info question

On 23 November 2010 18:03, Bagel <bagel99 at gmail.com> wrote: > Would someone be so kind as to tell me what the status of debugging symbols > (DWARF) generated by clang/llvm is? Hi Bagel, It should be fairly complete... > When I generate an executable with "clang -g" followed by "llc -O0" and feed it > to gdb, I get "no debugging symbols found".

Would someone be so kind as to tell me what the status of debugging symbols (DWARF) generated by clang/llvm is? I am on a linux x86-64 system (Fedora 13). Is gdb supposed to understand the generated DWARF? When I generate an executable with "clang -g" followed by "llc -O0" and feed it to gdb, I get "no debugging symbols found". What is the status of lldb on

On Mon, Dec 6, 2010 at 12:50 PM, Bagel <bagel99 at gmail.com> wrote: > On 12/06/2010 12:03 PM, Devang Patel wrote: > > As I understand, you are not interested in 'how to use DIFactory'. Do you > want > > to know what are the fields of metadata to encode debug info for a local > variable ? > > That'd be > > > > !7 = metadata !{ > >

On 12/03/2010 06:28 PM, Devang Patel wrote: > We are working on a document. Here is current draft: > http://wiki.llvm.org/Debug_Information > > - > Devang While this is great news, it doesn't completely satisfy my needs. Your documentation assumes one is going to use the LLVM provided functions (such as DIFactory::). My front-end can't use them because it is not

On 4 December 2010 21:16, bagel <bagel99 at gmail.com> wrote: > Perhaps you can add another section just on the textual format? Oh, perhaps you're looking for this: http://llvm.org/docs/SourceLevelDebugging.html cheers, --renato

On 02/16/2017 12:08 PM, Stephen Canon wrote: >> On Feb 16, 2017, at 9:12 AM, Bagel <bagel99 at gmail.com >> <mailto:bagel99 at gmail.com>> wrote: >> >> I figured that the optimization of this would bedifficult (else it would >> have already been done :-)) > > Don’t make this assumption. There’s lots of opportunities for optimization > scattered

> On Feb 21, 2017, at 9:54 PM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I believe that providing additional intrinsics that would directly produce the ISD::ADDC/ISD::SUBC nodes would provide the additional advantage of being able to directly produce these nodes for code that doesn't have anything to do with multiprecision addition/subtraction. I am

On 12/06/2010 12:03 PM, Devang Patel wrote: > As I understand, you are not interested in 'how to use DIFactory'. Do you want > to know what are the fields of metadata to encode debug info for a local variable ? > That'd be > > !7 = metadata !{ > i32, ;; Tag (see below) > metadata, ;; Context > metadata, ;; Name > metadata, ;; Reference to

Hi Devang, >> It does make me wonder how you are supposed to represent types which cannot >> be properly represented by LLVM types, for example structs with fields at >> variable offsets from the start and/or of variable size; or structs with >> fields that may or may not be present depending on the value of other fields. >> Such types occur in Ada for example. >

I'm trying to get the Ada gcc front-end to work with LLVM. This series of patches gets things to the point where the Ada compiler builds, though it fails to build itself or the runtime. While I was there I resurrected fortran and java: as with Ada, the compilers build but not the runtimes. Also, I've replaced the gcc 4.0 Ada front-end with a back-port of the Ada front-end from FSF gcc

I am writing a front end for a new language and am having trouble generating the DWARF debugging information. I'm outputting llvm assembly source so I'm trying to generate the "!metadata" stuff. I have found the document <http://llvm.org/docs/SourceLevelDebugging.html> a helpful start, as far as it goes. However, it doesn't quite match what I see clang produce

On 08/20/2010 04:06 PM, Eli Friedman wrote: > On Fri, Aug 20, 2010 at 1:03 PM, Bagel<bagel99 at gmail.com> wrote: >> I propose a new intrinsic "llvm.memcmp" that compares a block of memory >> for equality (a subset of the libc behavior). Backends are free to use the >> alignment to optimize using wider than byte operations. Since the result is >> only

I think I have read that there are plans to generate object code (e.g. ELF) directly in addition to assembly language source. If so, are there plans to support branch relaxation for targets which support long/short branch displacements? This is typically done in assemblers. thanks, bagel

> On Feb 5, 2017, at 7:13 PM, Rodney M. Bates via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > A couple of Modula-3 developers have worked on splicing LLVM on as an alternative > back end to the Modula-3 compiler, out-of-tree (the LLVM tree), of course. A major > portion of the necessary glue code is there, and at one time, I was able to get the > M3 compiler and the

On Dec 3, 2010, at 2:39 PM, Bagel wrote: > I am writing a front end for a new language and am having trouble generating > the DWARF debugging information. I'm outputting llvm assembly source so I'm > trying to generate the "!metadata" stuff. > > I have found the document <http://llvm.org/docs/SourceLevelDebugging.html> a > helpful start, as far as it

I am writing a backend for an experimental machine that has both 2-address and 3-address versions of some instructions. The 2-address versions are more compact and thus preferred when applicable. How does one go about generating the most compact version? 1. At instruction selection, is there a predicate that can test whether one of the input sources is dead, thus allowing the selection of the

Duncan, It would be useful to know what motivated this work -- in particular, is some organization (company, open source project team, research group, any other kind) interested in having an Ada front-end? Thanks, --Vikram ---------------------------------------------------------------------- VIKRAM S. ADVE Associate Professor, Computer Science E-MAIL: vadve at cs.uiuc.edu Siebel

On Fri, Aug 20, 2010 at 1:03 PM, Bagel <bagel99 at gmail.com> wrote: > I propose a new intrinsic "llvm.memcmp" that compares a block of memory > for equality (a subset of the libc behavior).  Backends are free to use the > alignment to optimize using wider than byte operations.  Since the result is > only equal/not-equal, byte order is not important. > > For

On 09/11/2014 05:33 PM, Quentin Colombet wrote: > Hi Brian, > > On Sep 11, 2014, at 3:03 PM, Bagel <bagel99 at gmail.com> wrote: > >> When the IR specifies a 32 bit load can it be changed to a narrower >> load? What if the load is from memory (e.g. a peripheral) that only >> supports 32-bit access? Consider the following IR: ---- target datalayout >> =

Hi, I am working on an issue where a subprogram created here is having abstract_origin pointing to nowhere. DIE *DwarfDebug::updateSubprogramScopeDIE(CompileUnit *SPCU, const MDNode *SPNode) { DIE *SPDie = SPCU->getDIE(SPNode); assert(SPDie && "Unable to find subprogram DIE!"); DISubprogram SP(SPNode); // If we're