<div dir="ltr">(oops, dropped the list by accident)<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">David Blaikie</b> <span dir="ltr"><<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>></span><br>Date: Fri, Feb 20, 2015 at 1:17 PM<br>Subject: Re: [LLVMdev] Parameter names in IR and debug info<br>To: <a href="mailto:rodney.m.bates@acm.org">rodney.m.bates@acm.org</a><br><br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Feb 20, 2015 at 1:01 PM, Rodney M. Bates <span dir="ltr"><<a href="mailto:rodney_bates@lcwb.coop" target="_blank">rodney_bates@lcwb.coop</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 02/19/2015 01:38 PM, David Blaikie wrote:<span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Thu, Feb 19, 2015 at 8:18 AM, Rodney M. Bates <<a href="mailto:rodney_bates@lcwb.coop" target="_blank">rodney_bates@lcwb.coop</a> <mailto:<a href="mailto:rodney_bates@lcwb.coop" target="_blank">rodney_bates@lcwb.coop</a><u></u>>> wrote:<br>
<br>
Have I correctly inferred below, how I build IR and debug info for<br>
a function type and a function (value), in particular, how to supply<br>
the names of the formal parameters?<br>
<br>
<br>
Generally good advice: <a href="http://llvm.org/docs/tutorial/LangImpl8.html" target="_blank">http://llvm.org/docs/tutorial/<u></u>LangImpl8.html</a><br>
<br>
To create a function in llvm IR and give names to its formal parameters,<br>
I must:<br>
<br>
1. Build a LLVMTypeRef for the type of each formal and the function result.<br>
<br>
<br>
Sounds like you're using the C API. I'm not especially familiar with that, so answers may be vague.<br>
<br>
2. Build a function type using LLVMFunctionType, from the results of 1.<br>
3. Build a function (an LLVMValueRef), using LLVMAddFunction, from the result of 2.<br>
4. Get the LLVMValueRef for each formal (apparently, these are constructed inside<br>
LLVMAddFunction), using LLVMGetParam, from the result of 3.<br>
5. Set the formal name using LLVMSetValueName, from each result of 5.<br>
<br>
<br>
The names of LLVM IR values are purely aids for LLVM developers (such as yourself), they should never have any impact on the result of LLVM (in terms of machine asm/code - the textual LLVM IR will include the names, but again, this is just a debugging aid for you, the LLVM developer (it has no impact on the DWARF debug info LLVM emits))<br>
<br>
</blockquote>
<br></span>
Thanks, that's useful info. I had wondered about that. In any case, I think I<br>
want the names just to help looking at IR code.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Which appears to imply that the formal names are part of the function,<br>
not the function type, and thus the function type could be reused for another<br>
function whose signature differs only in the names of the formals. Also the<br>
function type could be used as the referent of a pointer type, which could<br>
then be used as the type of a variable, without any actual function at all.<br>
<br>
<br>
Sure.<br>
<br>
<br>
To build corresponding debug info, I must:<br>
<br>
6. Build a llvm::DIArray, using llvm::getOrCreateArray, from the results of 4.<br>
7. Build a llvm::DIComposite type for the function, using<br>
llvm::createSubroutineType, from the result of 6.<br>
8. Build a llvm::DIFunction using llvm::createFunction, from the result of 7.<br>
<br>
Here, I need the formal values, with names, first, before building the function<br>
type.<br>
<br>
<br>
I don't think you should need parameter names for createSubroutineType - it's just a type (composed of other types, no variable names, just type names).<br>
<br>
</blockquote>
<br></span>
That's what I might have expected, but ... createSubroutineType wants a DIArray, and its<br>
creator getOrCreateArray, takes a list of Value*, not Type*.<br></blockquote></div></div><div><br>OK, so all the debug info is described by values, it doesn't depend on or use LLVM Type*s. You can have an i32 value in LLVM described by some complex user defined type (because, for example, your source language tells you to lower "struct foo { int x; };" to i32 in a calling convention, etc) in the debug info because that's how it was written in the source code.<br> </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(The Kaleidoscope chapter 8 uses getOrCreateTypeArray, returning DITypeArray, neither<br>
of which shows up in a systematic grep of the entire source tree.)</blockquote></span><div><br>Which source tree are you searching? DIBuilder::getOrCreateTypeArray is in include/llvm/IR/DIBuilder.h<br> </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This appears to imply that, in debug info, the formal names are also part<br>
of the function type,<br>
<br>
<br>
Shouldn't be. But the actual DWARF output doesn't necessarily have explicit function types - it just has a function with some formal parameters, each with a type and in a specified order.<br>
<br>
which thus cannot be reused for a different function with<br>
different formal names.<br>
<br>
Can I build a DI function type without having an actual function of that type?<br>
This happens in my language.<br>
<br>
<br>
Not sure I understand. You mean your language has, say, a function pointer even though you have no function of that type. Certainly clang does this (try compiling something simple like "void (*x)();" in clang and look at the LLVM IR it produces - you'd want to produce something similar).<br>
<br>
</blockquote>
<br></span>
Yes, actually, the HLL view is there are procedure types (not pointers to) that take values of<br>
any procedure whose signature meets a certain structural similarity criterion (weaker than equality)<br>
with the type. Of course, pointers are used in the implementation, but this is a lowering from<br>
the source code, complicated by the fact that sometimes the value can be a nested procedure, needing<br>
an environment.<br>
<br>
In order to support reasonable debugger behavior, using source language concepts, I need debug info for<br>
procedure types to have parameter names. </blockquote></span><div><br>It's possible that LLVM's debug info IR doesn't support this scenario. I'm not sure DWARF itself does either (hmm, well, a DW_TAG_subroutine_type has DW_TAG_formal_parameters for its parameter types, so in theory those could have DW_AT_names - but I don't think we support that in the IR at least & not sure if any existing debuggers would do anything useful with it if we did)<br> </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And better debugger behavior is one major reason for<br>
connecting to an llvm back end.<br>
<br>
One thing that makes it harder to figure out what I need to do is that many examples, e.g., clang-produced<br>
IR for sample C programs, give assembly. Translating this into the sequence of calls needed to<br>
build the in the in-memory form of IR is not always obvious.<br></blockquote></span><div><br>The Kaleidoscope examples should give some examples of API use. And/or you can jump into clang in a debugger & step through how it's building different things.<br> </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Actually, I am increasing doubting the wisdom of my initial decision to generate llvm IR this<br>
way. Maybe generating an assembly or bitcode file directly would be better.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
- David<br>
<br>
<br>
<br>
--<br>
Rodney Bates<br></span>
<a href="mailto:rodney.m.bates@acm.org" target="_blank">rodney.m.bates@acm.org</a> <mailto:<a href="mailto:rodney.m.bates@acm.org" target="_blank">rodney.m.bates@acm.org</a><u></u>><br>
______________________________<u></u>___________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/__<u></u>mailman/listinfo/llvmdev</a> <<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a>><br>
<br>
<br>
</blockquote><div><div>
<br>
-- <br>
Rodney Bates<br>
<a href="mailto:rodney.m.bates@acm.org" target="_blank">rodney.m.bates@acm.org</a><br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></span></div><br></div></div>
</div><br></div>