similar to: [LLVMdev] Feeding DWARF debug information for an LLVM module

Hi, First, considering I'm using an IRBuilder and a DIBuilder to build my program, how can I automatically bind the CreateAlloca with my named local variable inside the DIBuilder ? Is it automatic with the Twine name of CreateAlloca ? And/Or should I use DIBuilder::createAutoVariable and how ? Then, I'm wondering how to locate back my local variable in memory (register or stack) once i

Binding the alloca to the debug-info metadata is not automatic. You need to emit an intrinsic function call to llvm.dbg.declare to bind the two together. If you are simply trying to emit DWARF for your program, the rest of the processing should already be in place for that. If you are trying to do something else, you would need to describe that so we understand what you need. --paulr From:

Adding tags on subject line From: Chirag Patel Sent: 22 August 2018 11:20 To: llvm-dev at lists.llvm.org Subject: DIBuilder missing interface to generate DWARF info for packed_decimal basic type. Hello, I am working on a llvm based compiler frontend in which, I am using the packed_decimal type encoding. During using the llvm DIBuilder, I found out that the interface to create BasicType with

Hi Paul, How can i make this call to intrinsic from the c++ code ? I'm not working with the IR language, but directly in C++ with IRBuilder::CreateAlloca. My goal is that one : - Generate machine code with an instance of the class 'IRBuilder' - Emit 'ObjFile' class instance with MCJIT - Create a DwarfContext instance directly from the emitted ObjFile object

"IR" often refers to the general concept/semantics, not only the textual format in .ll files (there are 3 main forms - bitcode, textual IR, and the in-memory representation (llvm::Module, etc - constructed using IRBuilder)). A great place to start is to look at what Clang does to produce debug info - it uses IRBuilder, for instance. So you could look at how Clang uses the IRBuilder when

Hello Paul, Thanks for the reply. Yes, I am only looking for dwarf support at the moment and planning to support both PLI/COBOL decimal types. Also thanks for the suggestion, you are right as it is going to be rare cases, so it will be better to implement a separate subclass to avoid memory overhead for others. >> (Somebody is actively working on scaled binary operations, although they

I wanted to check that I'm headed in the right direction before I work more on LLVM debug info. What I'd like to do is update DIBuilder to expose exactly the facilities represented in modern DWARF, and to store that in the bitcode. In LLVM we would have a DwarfOpts that specifies the major version of DWARF we're targetting and some additional compatibility flags to work around debugger

Talin, You're developing your own language and tool sets, it brings fresh perspective in our predominately C orientated environment, which is good. On Apr 1, 2011, at 8:12 PM, Talin wrote: > Is this a limitation of DWARF or of the LLVM generator? Neither, IMO. My own reading of DWARF did not find clear wording on this subject. I am not even sure if it is just a darwin gdb implementation

On Thu, Mar 31, 2011 at 9:15 AM, Devang Patel <dpatel at apple.com> wrote: > > On Mar 31, 2011, at 12:57 AM, Talin wrote: > > On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > >> >> On Mar 29, 2011, at 7:29 PM, Talin wrote: >> >> I've been trying to track down the problem with the DWARF info that is >> being

On 28 June 2012 10:15, Duncan Sands <baldrick at free.fr> wrote: >> I wanted to check that I'm headed in the right direction before I work more on >> LLVM debug info. What I'd like to do is update DIBuilder to expose exactly the >> facilities represented in modern DWARF, > > wouldn't it be better in the long term to make the debug info layer more >

Renato, On Mar 17, 2011, at 3:25 AM, Renato Golin wrote: > could help with the verification process (since it's much better to > fail verification than to fail gdb testuite), but I don't know the > design decisions being taken for debug information/metadata, and they > change too frequently to dig the code to learn. I think you are mistaken here. I maintain and support

On 28/06/12 11:29, Renato Golin wrote: > On 28 June 2012 10:15, Duncan Sands <baldrick at free.fr> wrote: >>> I wanted to check that I'm headed in the right direction before I work more on >>> LLVM debug info. What I'd like to do is update DIBuilder to expose exactly the >>> facilities represented in modern DWARF, >> >> wouldn't it be

On 17 March 2011 13:48, Devang Patel <dpatel at apple.com> wrote: > I think you are mistaken here. I maintain and support debug info for two front ends (llvm-gcc and clang). Go ahead and check svn archives for last one year and see how many times I had to update llvm-gcc FE. Hi Devang, First, I'm not attacking anyone. I said before and will say again: the work you've done is

I'm trying to write a llvm pass to add debug info into a non-debug-info bitcode file. I have been read http://llvm.org/docs/SourceLevelDebugging.html. And I use DIBuilder to produce the debug metadata. I know I can't get all information form ir code . So I add some manual info as test data. After executing my pass, I can find debug info metadata in my generated bitcode. Those metadata

On Mar 17, 2011, at 7:29 AM, Renato Golin wrote: > On 17 March 2011 13:48, Devang Patel <dpatel at apple.com> wrote: >> I think you are mistaken here. I maintain and support debug info for two front ends (llvm-gcc and clang). Go ahead and check svn archives for last one year and see how many times I had to update llvm-gcc FE. > > Hi Devang, > > First, I'm not

The Rust compiler defines all functions as returning void, with the first parameter being an outparam of the declared return type, ie. fn foo2() -> int { ret 5; } becomes define void @_ZN4foo217_5cb557d30658848cE(i64*, { i64, { %tydesc*, i1, {} } }*) uwtable { store i64 5, i64* %0 ret void } I'm working on generating debug information for Rust, and I'm currently stumped on how

I recently upgraded a codebase to use LLVM 3.9.0, up from 3.7.1. All seems to work well, except that I am unable to generate debug information. However, if I run objdump -g on the generated object file, it reports that the compile unit has no children: Contents of the .debug_abbrev section: Number TAG (0x0) 1 DW_TAG_compile_unit [no children] DW_AT_producer DW_FORM_strp

Hi Nick, > I wanted to check that I'm headed in the right direction before I work more on > LLVM debug info. What I'd like to do is update DIBuilder to expose exactly the > facilities represented in modern DWARF, wouldn't it be better in the long term to make the debug info layer more abstract rather than a direct mapping onto dwarf? Ciao, Duncan. and to store that in

Hey folks, I'm wrestling with adding DWARF source code file/line information to my generated LLVM-IR from my Common Lisp compiler. I think I'm doing everything properly using the llvm::DIBuilder class - but when I load my Common Lisp application and load a compiled bundle into it I don't seem to be able to access the metadata properly. I can list source lines using "l -f

On Mar 31, 2011, at 12:57 AM, Talin wrote: > On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Mar 29, 2011, at 7:29 PM, Talin wrote: > >> I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb