(0036138)
Brad King (manager)
2014-06-09 15:51

Do you mean allowing something like

enable_language(LLVM-IR)

?

FYI, the Modules/CMakeAddNewLanguage.txt file in the source tree covers some of the steps needed to add a new language.

(0036142)
sdough (reporter)
2014-06-09 16:14

Yes, I think so. Would it make sense for the language to link the libraries each executable uses, or have a (language-specific?) option to do so? I ask because in the case of KLEE it cannot evaluate parts of the program that do not have library bitcode linked in.

I also mislabeled KLEE as static analysis - it interprets the bitcode.

(0036143)
Brad King (manager)
2014-06-09 16:23

Re 0014965:0036142: I'm not sure what you mean. Can you provide an example CMakeLists.txt snippet that you imagine being enabled by this feature, and the corresponding behavior (compile+link) it would produce?

(0036151)
sdough (reporter)
2014-06-10 10:37

I'm not sure how much of this is a general use case, but libraries would be passed to the linker as bitcode files so that the entire program can be interpreted in bitcode. llvm-link does not support "-static", or "-l" library specifications as included by C's <LINK_LIBRARIES> linking rule.

CMakeList.txt:
project(test LLVM-IR)

add_library(proj_lib SHARED
    lib.c
)

add_executable(server
    server.c
)

target_link_libraries(server
    pthread
    proj_lib
)

This would compile with "clang -emit-llvm", and link with llvm-link:

clang -c -emit-llvm server.c -o server.c.o
clang -c -emit-llvm lib.c -o lib.c.o
llvm-link server.c.o lib.c.o /path/to/pthread.bc -o myprog

I don't know how LLVM IR bitcode for libraries like pthread would come to exist. I've shown shared libraries behaving differently here in the hope that the same project can build as LLVM-IR and as C/C++.

(0036152)
Brad King (manager)
2014-06-10 11:07

Re 0014965:0036151: Okay, so this is not what I had in mind in 0014965:0036138 at all. It is not a new compiled language. It is still C, just with different compile/link commands.

In the example link line did you mean to include "/path/to/proj_lib.bc" in addition to "/path/to/pthread.bc" or instead of it?

(0036154)
sdough (reporter)
2014-06-10 11:19

In addition to /path/to/pthread.bc. lib.c.o in the example link line is a debatable name for what you refer to as proj_lib.bc. It would probably make sense for LLVM-IR build products to all have a ".bc" extension.

(0036155)
Brad King (manager)
2014-06-10 11:39

Re 0014965:0036154: Thanks. This sounds similar to cross-compiling since all the binaries will have names/extensions not typically used on the host.

(0042563)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Notes
(0036138) Brad King (manager) 2014-06-09 15:51	Do you mean allowing something like enable_language(LLVM-IR) ? FYI, the Modules/CMakeAddNewLanguage.txt file in the source tree covers some of the steps needed to add a new language.

(0036142) sdough (reporter) 2014-06-09 16:14	Yes, I think so. Would it make sense for the language to link the libraries each executable uses, or have a (language-specific?) option to do so? I ask because in the case of KLEE it cannot evaluate parts of the program that do not have library bitcode linked in. I also mislabeled KLEE as static analysis - it interprets the bitcode.

(0036143) Brad King (manager) 2014-06-09 16:23	Re 0014965:0036142: I'm not sure what you mean. Can you provide an example CMakeLists.txt snippet that you imagine being enabled by this feature, and the corresponding behavior (compile+link) it would produce?

(0036151) sdough (reporter) 2014-06-10 10:37	I'm not sure how much of this is a general use case, but libraries would be passed to the linker as bitcode files so that the entire program can be interpreted in bitcode. llvm-link does not support "-static", or "-l" library specifications as included by C's <LINK_LIBRARIES> linking rule. CMakeList.txt: project(test LLVM-IR) add_library(proj_lib SHARED lib.c ) add_executable(server server.c ) target_link_libraries(server pthread proj_lib ) This would compile with "clang -emit-llvm", and link with llvm-link: clang -c -emit-llvm server.c -o server.c.o clang -c -emit-llvm lib.c -o lib.c.o llvm-link server.c.o lib.c.o /path/to/pthread.bc -o myprog I don't know how LLVM IR bitcode for libraries like pthread would come to exist. I've shown shared libraries behaving differently here in the hope that the same project can build as LLVM-IR and as C/C++.

(0036152) Brad King (manager) 2014-06-10 11:07	Re 0014965:0036151: Okay, so this is not what I had in mind in 0014965:0036138 at all. It is not a new compiled language. It is still C, just with different compile/link commands. In the example link line did you mean to include "/path/to/proj_lib.bc" in addition to "/path/to/pthread.bc" or instead of it?

(0036154) sdough (reporter) 2014-06-10 11:19	In addition to /path/to/pthread.bc. lib.c.o in the example link line is a debatable name for what you refer to as proj_lib.bc. It would probably make sense for LLVM-IR build products to all have a ".bc" extension.

(0036155) Brad King (manager) 2014-06-10 11:39	Re 0014965:0036154: Thanks. This sounds similar to cross-compiling since all the binaries will have names/extensions not typically used on the host.

(0042563) Kitware Robot (administrator) 2016-06-10 14:29	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2014-06-09 15:05	sdough	New Issue
2014-06-09 15:51	Brad King	Note Added: 0036138
2014-06-09 16:14	sdough	Note Added: 0036142
2014-06-09 16:23	Brad King	Note Added: 0036143
2014-06-10 10:37	sdough	Note Added: 0036151
2014-06-10 11:07	Brad King	Note Added: 0036152
2014-06-10 11:19	sdough	Note Added: 0036154
2014-06-10 11:39	Brad King	Note Added: 0036155
2016-06-10 14:29	Kitware Robot	Note Added: 0042563
2016-06-10 14:29	Kitware Robot	Status	new => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships