[cfe-dev] output metadata for extern declared functions?
Lewis Young (lu zhao)
lewisurn at gmail.com
Sat Nov 9 15:21:46 PST 2013
Can you please be more specific about the imported directives, such as
the names of related classes? I'm totally new to Clang and only used
little about LLVM.
I took a look at clang::CodeGen::CGDebugInfo and it seems that it uses
llvm::DIBuilder as the underlying horsepower. I played with the if
statements related to "isDefinition" in DIBuilder::createFunction and
DIBuilder::createMethod, and it didn't work. Obviously, I've missed many
things here.
Since generating debug info metadata has been done for function
definitions, so conceptually generating the same type of data for
declarations should be easier. I might be wrong though. The more
specific you can point me to some code, the better.
Thanks very much,
On 11/09/2013 02:23 PM, David Blaikie wrote:
>
> Generally we don't encourage source to source translation via code
> generation from the AST even - its best to use the AST to motivate
> edits to the original source. The AST just doesn't have the fidelity
> to regenerate the original source perfectly.
>
> As for your current problem, I guess 'is it cheaper to rewrite in a
> better way' depends on the complexity, but i assume its hard to
> justify a rewrite unless this tool is going to live a long time
> further and need new features/maintenance.
>
> That said, I'm not sure how much I can help you produce debug info for
> every function declaration. If I were doing this I'd go back and look
> at the support I added for imported directives (using declarations and
> directives) and look at other unhandled decks that could be supported.
>
> On Nov 9, 2013 10:18 AM, "Lewis Burns" <lewisurn at gmail.com
> <mailto:lewisurn at gmail.com>> wrote:
>
> I'm fixing an existing source-to-source translator, and it was
> unfortunately written by someone using LLVM as the intermediate
> step before Clang was mature. I don't need to generate object code
> at all, and performance is not a concern here.
>
> Sounds like that the only way for me to save this translator is to
> patch Clang by generating debug info metadata for declarations
> whose definitions are not available. Is this a feasible approach?
> I mean how difficult it would be comparing with hacking into Clang
> AST and start from there? I guessed that it would be much easier
> than starting over with Clang AST from scratch. Since I haven't
> worked on Clang before, any suggestion and help would be greatly
> 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/20131109/591c43d5/attachment.html>
More information about the cfe-dev
mailing list