llvm dev - Dec 2016 - cross-checking external declarations / debug info for declarations

I am interested in putting together a tool which can verify that an external
declaration conforms with the actual definition.

A.c:
extern int32_t foo();
Int bar() { return foo(); }

B.c:
int64_t foo() {  ... }

I had thought that I could use the debug information but the debug information
in A.o does not include the type of the declaration "foo", just the
type of bar.

Is there a way to include declarations as well as definitions such as a above?
It appears there is a notion of "retained" types, perhaps I add a flag
to retain declarations?

Perhaps a different approach?

Thanks
-david



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161208/aa6e9a87/attachment.html>

Have you considered creating a clang-based tool?

I'd approach this by creating a RecursiveASTVisitor, overriding
VisitFuncDecl,
and dumping out the return / param types. You can mark extern decls in some
way, sort the output, and check for inconsistencies.

One advantage over looking at IR is that you don't have to use the
extern'd
decl in a TU to have it show up.

vedant
> On Dec 8, 2016, at 7:43 AM, David Callahan via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I am interested in putting together a tool which can verify that an
external declaration conforms with the actual definition.
> 
> A.c:
> extern int32_t foo();
> Int bar() { return foo(); }
> 
> B.c:
> int64_t foo() {  … } 
> 
> I had thought that I could use the debug information but the debug
information in A.o does not include the type of the declaration “foo”, just the
type of bar.
> 
> Is there a way to include declarations as well as definitions such as a
above? It appears there is a notion of “retained” types, perhaps I add a flag to
retain declarations?
> 
> Perhaps a different approach?
> 
> Thanks
> —david
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi Vendant,

Thanks for the suggestion, I had not considered that you.

A real advantage to working with debug info is that the tool could be
implemented as a linker plugin which would avoid dealing with
false-positives in a large code pass which may include multiple versions
of some libraries. But after poking into the code that determines what
debug info to emit, a small change there looks to he non-trivial.

‹david

On 12/8/16, 5:50 PM, "vsk at apple.com on behalf of Vedant Kumar"
<vsk at apple.com> wrote:
>Have you considered creating a clang-based tool?
>
>I'd approach this by creating a RecursiveASTVisitor, overriding
>VisitFuncDecl,
>and dumping out the return / param types. You can mark extern decls in
>some
>way, sort the output, and check for inconsistencies.
>
>One advantage over looking at IR is that you don't have to use the
>extern'd
>decl in a TU to have it show up.
>
>vedant
>
>> On Dec 8, 2016, at 7:43 AM, David Callahan via llvm-dev
>><llvm-dev at lists.llvm.org> wrote:
>> 
>> I am interested in putting together a tool which can verify that an
>>external declaration conforms with the actual definition.
>> 
>> A.c:
>> extern int32_t foo();
>> Int bar() { return foo(); }
>> 
>> B.c:
>> int64_t foo() {  Š }
>> 
>> I had thought that I could use the debug information but the debug
>>information in A.o does not include the type of the declaration ³foo²,
>>just the type of bar.
>> 
>> Is there a way to include declarations as well as definitions such as a
>>above? It appears there is a notion of ³retained² types, perhaps I add a
>>flag to retain declarations?
>> 
>> Perhaps a different approach?
>> 
>> Thanks
>> ‹david
>> 
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> 
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2D
>>bin_mailman_listinfo_llvm-2Ddev&d=DgIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=lFyiP
>>UrFdOHdaobP7i4hoA&m=GaJ34if4WSRp77tdn87cs98gRs10AaGII68Amd-bPYc&s=NZY7CVI
>>YwcOs5kLY554eVrna2P6O-0HLV63263xaffc&e>

> On Dec 8, 2016, at 7:43 AM, David Callahan via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I am interested in putting together a tool which can verify that an
external declaration conforms with the actual definition.
> 
> A.c:
> extern int32_t foo();
> Int bar() { return foo(); }
> 
> B.c:
> int64_t foo() {  … } 
> 
> I had thought that I could use the debug information but the debug
information in A.o does not include the type of the declaration “foo”, just the
type of bar.
> 
> Is there a way to include declarations as well as definitions such as a
above? It appears there is a notion of “retained” types, perhaps I add a flag to
retain declarations?
You should take a look at

https://reviews.llvm.org/D18565

which implements (almost?) all that you're asking for.

-- adrian
> 
> Perhaps a different approach?
> 
> Thanks
> —david
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Great, thanks Adrian, I will try it.

On 12/9/16, 9:00 AM, "aprantl at apple.com on behalf of Adrian Prantl"
<aprantl at apple.com> wrote:
>
>> On Dec 8, 2016, at 7:43 AM, David Callahan via llvm-dev
>><llvm-dev at lists.llvm.org> wrote:
>> 
>> I am interested in putting together a tool which can verify that an
>>external declaration conforms with the actual definition.
>> 
>> A.c:
>> extern int32_t foo();
>> Int bar() { return foo(); }
>> 
>> B.c:
>> int64_t foo() {  Š }
>> 
>> I had thought that I could use the debug information but the debug
>>information in A.o does not include the type of the declaration ³foo²,
>>just the type of bar.
>> 
>> Is there a way to include declarations as well as definitions such as a
>>above? It appears there is a notion of ³retained² types, perhaps I add a
>>flag to retain declarations?
>
>You should take a look at
>
>https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D185
>65&d=DgIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=lFyiPUrFdOHdaobP7i4hoA&m=KSgUa2B5f2
>BhzgOkgNpRGZB7wwdvfbqiR6RLLzxJIxc&s=-wOXH9x17xU-PsJHUesmsXqyb0iiHgL4h8WoAg
>rKq20&e= 
>
>which implements (almost?) all that you're asking for.
>
>-- adrian
>
>> 
>> Perhaps a different approach?
>> 
>> Thanks
>> ‹david
>> 
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> 
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2D
>>bin_mailman_listinfo_llvm-2Ddev&d=DgIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=lFyiP
>>UrFdOHdaobP7i4hoA&m=KSgUa2B5f2BhzgOkgNpRGZB7wwdvfbqiR6RLLzxJIxc&s=Vty1myn
>>O85AFVwSB_Xtx8mgNl__zibErYfYUZYZpmF0&e>

> On Dec 9, 2016, at 2:16 PM, David Callahan <dcallahan at fb.com>
wrote:
> 
> Adrian, this appears to generate, in my example below, the return type for
> the external function (“foo” below) but does not generate a (in Dwarf)
> DW_TAG_Subprogram which binds that type to the name. Is that expected?
> 
We are probably not visiting forward declarations in CGDebugInfo. You would
probably need to visit them and call something like
CGDebugInfo::getFunctionForwardDeclaration() on each declaration.

-- adrian

I was able to add a call to EmitFunctionDecl in
lib/CodeGen/CodeGenModule.cpp and then needed a corresponding LLVM change
to handle Subprogram¹s in the retained type vector.

The diff D18565 is marked Abandoned. What is the future plans for
supporting full-type consumers?

On 12/9/16, 2:24 PM, "aprantl at apple.com on behalf of Adrian Prantl"
<aprantl at apple.com> wrote:
>
>
>> On Dec 9, 2016, at 2:16 PM, David Callahan <dcallahan at fb.com>
wrote:
>> 
>> Adrian, this appears to generate, in my example below, the return type
>>for
>> the external function (³foo² below) but does not generate a (in Dwarf)
>> DW_TAG_Subprogram which binds that type to the name. Is that expected?
>> 
>
>We are probably not visiting forward declarations in CGDebugInfo. You
>would probably need to visit them and call something like
>CGDebugInfo::getFunctionForwardDeclaration() on each declaration.
>
>-- adrian