llvm dev - Mar 2010 - [LLVMdev] Extracting type information from header files

Hi,

I would like to generate an LLVM bitcode file that contains all the types and
functions declared in a header file.
For example, the following code should make the llvm compiler put all type
information contained in stdio.h in the resulting bitcode file.

#include <stdio.h>

int main()
{
  return 0;
}

Unfortunately, when compiled with "llvm-gcc -g -emit-llvm -c test.c",
the resulting bitcode does not contain any type information from stdio.h.
After some investigation, it appears that llvm-gcc keeps only the relevant
types, that are used somewhere in the program. For example, the following code
results in a FILE structure to be embedded in the bitcode:
#include <stdio.h>

int main()
{
  FILE *fp;
  return 0;
}

Is there a command line switch to include all type information, even for unused
types?

Thanks for your help.

Vitaly C.

Hello Vitaly,

Clang supports LLVM Bitcode formatted precompiled headers if that is what you
are looking for.  LLVM-GCC might be a different story though.  Also note that
these headers will be different from one operating system to the next.  If
you're looking for something portable, test out my wrapper at
http://sourceforge.net/projects/llvmlibc/ in the SVN repo.

--Sam



----- Original Message ----
> From: Chipounov Vitaly <vitaly.chipounov at epfl.ch>
> To: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
> Sent: Wed, March 3, 2010 2:46:41 PM
> Subject: [LLVMdev] Extracting type information from header files
> 
> Hi,
> 
> I would like to generate an LLVM bitcode file that contains all the types
and
> functions declared in a header file.
> For example, the following code should make the llvm compiler put all type 
> information contained in stdio.h in the resulting bitcode file.
> 
(snip)
> Is there a command line switch to include all type information, even for
unused
> types?
> 
> Thanks for your help.
> 
> Vitaly C.

Samuel,

Thanks for your advice. 
llvm-gcc seems to emit precompiled headers (*.gch) in a non-llvm format
(llvm-gcc -emit-llvm  -g  test.h)
I will try with Clang.

Vitaly C.

________________________________________
From: Samuel Crow [samuraileumas at yahoo.com]
Sent: Wednesday, March 03, 2010 22:14
To: Chipounov Vitaly; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Extracting type information from header files

Hello Vitaly,

Clang supports LLVM Bitcode formatted precompiled headers if that is what you
are looking for.  LLVM-GCC might be a different story though.  Also note that
these headers will be different from one operating system to the next.  If
you're looking for something portable, test out my wrapper at
http://sourceforge.net/projects/llvmlibc/ in the SVN repo.

--Sam



----- Original Message ----
> From: Chipounov Vitaly <vitaly.chipounov at epfl.ch>
> To: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
> Sent: Wed, March 3, 2010 2:46:41 PM
> Subject: [LLVMdev] Extracting type information from header files
>
> Hi,
>
> I would like to generate an LLVM bitcode file that contains all the types
and
> functions declared in a header file.
> For example, the following code should make the llvm compiler put all type
> information contained in stdio.h in the resulting bitcode file.
>
(snip)
> Is there a command line switch to include all type information, even for
unused
> types?
>
> Thanks for your help.
>
> Vitaly C.

On Mar 3, 2010, at 1:14 PM, Samuel Crow wrote:
> Clang supports LLVM Bitcode formatted precompiled headers if that is what
you are looking for.  LLVM-GCC might be a different story though.  Also note
that these headers will be different from one operating system to the next.  If
you're looking for something portable, test out my wrapper at
http://sourceforge.net/projects/llvmlibc/ in the SVN repo.
Clang's PCH format is Clang AST bitcode, not LLVM bitcode.  If we stored PCH
as LLVM IR we'd lose enormous amounts of information even from C, and
Objective C and C++ would be completely impossible.

They use the same binary-stream library, but that's where the similarities
end.

John.