[cfe-dev] output metadata for extern declared functions?
Lewis Burns
lewisurn at gmail.com
Mon Nov 11 16:13:31 PST 2013
No, I don't care about those functions that aren't called.
Okay, I walked through the EmitCall family of functions of
CodeGenFunction, but didn't notice much. I guess that I'll have to trace
them through more carefully to see when it is done.
My thought is to copy the debug info metadata emission logic used during
generating the function prolog to function declarations. Do you think if
it works?
Thanks,
On 11/12/2013 07:49 AM, David Blaikie wrote:
> Do you care about generating debug info for declarations of functions
> that aren't even called? If so, then the approach you're taking will
> be insufficient (since we won't even emit an IR declaration for such a
> function)
>
> If not, then you might want to take a look at where the IR for the
> call is constructed (I don't know where this is, but you seem to be
> gaining some proficiency tracing through Clang/LLVM internals that
> will serve you well here) and then see how the target of the call is
> built and passed in to that.
>
>
> On Mon, Nov 11, 2013 at 3:44 PM, Lewis Burns <lewisurn at gmail.com
> <mailto:lewisurn at gmail.com>> wrote:
>
> I ran Clang in a debugger and traced how debug info metadata was
> emitted. It's a part of code generation of functions.
>
> I have a question about when the declaration of an extern function
> is emitted. For example, I have very simple code:
>
> extern int convert(unsigned u);
>
> void foo() {
> int x = convert(0);
> }
>
> The corresponding LLVM code is:
>
> ...
> ; Function Attrs: nounwind uwtable
> define void @foo() #0 {
> entry:
> %x = alloca i32, align 4
> call void @llvm.dbg.declare(metadata !{i32* %x}, metadata !8),
> !dbg !10
> %call = call i32 @convert(i32 0), !dbg !10
> store i32 %call, i32* %x, align 4, !dbg !10
> ret void, !dbg !11
> }
> ...
> declare i32 @convert(i32) #2 // when this line is emitted
>
> My question is where the "declare i32 @convert(i32) #2" line is
> emitted. I tried many breakpoints in EmitXXX family of functions
> in CodeGenModule and noticed that this piece of code
>
> // Ignore declarations, they will be emitted on their first use.
> if (const FunctionDecl *FD = dyn_cast<FunctionDecl>(Global)) {
> // Forward declarations are emitted lazily on first use.
> if (!FD->doesThisDeclarationHaveABody()) {
> if (!FD->doesDeclarationForceExternallyVisibleDefinition())
> return;
>
> causes the postpone of emission of the convert function
> declaration, but I couldn't figure out where and when the
> declaration is emitted. I set a breakpoint in the
> CodeGenModule::EmitDeferred() function, but nothing was done in
> that function.
>
> Any help is really appreciated.
>
>
> On 11/09/2013 04:14 PM, David Blaikie wrote:
>>
>> For those following this thread a critical detail would be that
>> you want debug info metadata.
>>
>> There's no simple flag for this as we don't attach the function
>> debug info metadata to every declaration, just to definitions
>> (there's no filtering step)
>>
>> But why do you want this anyway? If you're performing
>> optimizations/transformations based on debug info metadata,
>> that's not really the desired approach. Debug info is not meant
>> to affect code generation.
>>
>> On Nov 9, 2013 7:59 AM, "Lewis Burns" <lewisurn at gmail.com
>> <mailto:lewisurn at gmail.com>> wrote:
>>
>> Hi,
>>
>> I haven't worked on Clang before and have a simple question
>> (supposedly) for those who are familiar with metadata and
>> LLVM bitcode generation. Assume that I have a function which
>> is declared as extern as the following:
>>
>> extern int convert(unsigned u);
>>
>> I want to have Clang generate metadata nodes for it by adding
>> a metadata node of subprogram into the list of subprograms
>> defined in the current compilation unit. The subprogram
>> metadata node and its associated nodes should have the info
>> of the type signature. For example, I get the following set
>> of metadata nodes for function
>>
>> int convert(unsigned u) {return 0;}
>>
>> !3 = metadata !{metadata !4, metadata !10, metadata !33}
>> !4 = metadata !{i32 786478, metadata !1, metadata !5,
>> metadata !"convert", metadata !"convert", metadata !"", i32
>> 23, metadata !6, i1 false, i1 true, i32 0, i32 0, null, i32
>> 256, i1 false, i32 (i32)* @convert, null, null, metadata !2,
>> i32 23} ; [ DW_TAG_subprogram ] [line 23] [def] [convert]
>> !7 = metadata !{metadata !8, metadata !9}
>> !8 = metadata !{i32 786468, null, null, metadata !"int", i32
>> 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type
>> ] [int] [line 0, size 32, align 32, offset 0, enc DW_ATE_signed]
>> !9 = metadata !{i32 786468, null, null, metadata !"unsigned
>> int", i32 0, i64 32, i64 32, i64 0, i32 0, i32 7} ; [
>> DW_TAG_base_type ] [unsigned int] [line 0, size 32, align 32,
>> offset 0, enc DW_ATE_unsigned]
>>
>> which allows me to extract the source-level type signature
>> for the function by using LLVM debug info APIs. I'd like to
>> get the source-level type signature of the extern declared
>> function, but Clang does not produce metadata for it.
>>
>> By looking at the Clang AST for the extern declared function
>>
>> |-FunctionDecl 0x70598c0 <line:23:1, col:30> convert 'int
>> (unsigned int)' extern
>> | |-ParmVarDecl 0x7059800 <col:20, col:29> u 'unsigned int'
>>
>> I know that Clang has the information I need, and I just need
>> to turn off or remove the filter that ignores functions whose
>> bodies are not available during metadata node or/and code
>> generation. Are there simple switches that do this? If not,
>> can anyone please explain how to do it by pointing me to the
>> right code snippets?
>>
>> Thanks very much,
>>
>> --
>> Lewis
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
> --
> Lewis
>
>
--
Lewis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131112/2b46b024/attachment.html>
More information about the cfe-dev
mailing list