llvm dev - Sep 2013 - [LLVMdev] RFC: llvm-shlib-test (Was: [llvm] r191029 - llvm-c: Make LLVMGetFirstTarget a proper prototype)

Moving this to llvmdev.

On Fri, Sep 20, 2013 at 08:26:41AM +0200, Anders Waldenborg
wrote:
> > > This avoids warnings when included in a application that
> > > uses -Wstrict-prototypes.
> > >
> > 
> > Should we enable this warning in CFLAGS for LLVM builds to catch this
> > sooner?
> 
> It is a C-only warning, and AFAICS there is no C code in that uses
> llvm-c in the llvm source tree where this warning could be added.
> 
> That said I think it would be good if there was some test for the C
> API that compiled and linked againts libLLVM-X.so to make sure that
> works properly and there has not sneaked in some c++ in the header
> files. Something like c-index-test in clang, but unfortunately I guess
> llvm-c is to diverse to be put in a single tool like that.
Hacked up the beginnings of small tool for this. Find it attached. 

Does it make sense? Is this something that should be finished up and
included?

I doubt it will ever be able to reach good coverage over the llvm-c
api. But it should be a quick smoke test to verify that it works at
all, and that no c++-ism has been introduced in the headers that are
included from C. And of course add the "-Wstrict-prototypes" warning.

 anders
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RFC-llvm-shlib-test.patch
Type: text/x-diff
Size: 9333 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130923/2bb7c068/attachment.patch>

I like the idea, but I find the name confusing; I think it should have
`llvm-c` or `c-api` somewhere in the name. This could also serve as a
simple example of using the API.

-- Sean Silva


On Mon, Sep 23, 2013 at 4:00 PM, Anders Waldenborg <anders at 0x63.nu>
wrote:
> Moving this to llvmdev.
>
> On Fri, Sep 20, 2013 at 08:26:41AM +0200, Anders Waldenborg wrote:
> > > > This avoids warnings when included in a application that
> > > > uses -Wstrict-prototypes.
> > > >
> > >
> > > Should we enable this warning in CFLAGS for LLVM builds to catch
this
> > > sooner?
> >
> > It is a C-only warning, and AFAICS there is no C code in that uses
> > llvm-c in the llvm source tree where this warning could be added.
> >
> > That said I think it would be good if there was some test for the C
> > API that compiled and linked againts libLLVM-X.so to make sure that
> > works properly and there has not sneaked in some c++ in the header
> > files. Something like c-index-test in clang, but unfortunately I guess
> > llvm-c is to diverse to be put in a single tool like that.
>
> Hacked up the beginnings of small tool for this. Find it attached.
>
> Does it make sense? Is this something that should be finished up and
> included?
>
> I doubt it will ever be able to reach good coverage over the llvm-c
> api. But it should be a quick smoke test to verify that it works at
> all, and that no c++-ism has been introduced in the headers that are
> included from C. And of course add the "-Wstrict-prototypes"
warning.
>
>  anders
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130923/035b0b63/attachment.html>

On Mon, Sep 23, 2013 at 07:48:45PM -0400, Sean Silva
wrote:
> I like the idea, but I find the name confusing; I think it should have
> `llvm-c` or `c-api` somewhere in the name. This could also serve as a
> simple example of using the API.
I had it as llvm-c-test first, then noticed that the shared library's
directory was named "llvm-shlib". 

Yes, making sure it serves as a good example of using the API is a
good idea. Not sure all tests would be that, but it is a good goal.

The tests I have in mind are:

 * --dump-module
     basically just llvm-dis, tests memorybuffer/bitreader
     already implemented in patch, uncertain about protability as it
     does dup2 tricks to dump to stdout

 * --list-module-functions
     tests basic iteration over stuff in module
     implemented in patch, want to extend it to iterate over
     instructions too

 * --list-module-globals
     ditto

 * --disassemble
     Test llvm-c/Disassebler.h. Not sure about input format,
     lines of cpu name + hexdumped asm maybe is easiest for FileCheck
     
 * --objdump
     Test llvm-c/Object.h. List sections and symbols of an object file.     

 * --list-targets
     LLVMGetFirstTarget/LLVMGetNextTarget and whatever can be extracted
     from them

 * --calc
     Test Core.h irbuilding and possibly executionengine. Create a module
     with a function evaluating the specified aritmetic expression.
     Possibly generating machinecode and executing.

 anders