compilation/installation issues

[251]

Hi,

I updated my SVF installation and came across some issues (at least in my opinion):

• svf/include/SVFIR/SVFType.h lacks #include <cstdint> (compilation fails)
• I had to override -Werror with CXXFLAGS="-Wno-error=overloaded-virtual" to get it to compile with gcc 13.2.1
• make install does not copy libSvfCore.a, Util/config.h, and extapi.bc (which actually is an .ll file, not a .bc file)
• ExtAPI::getExtBcPath() needs some improvements:
  

  SVF/svf/lib/Util/ExtAPI.cpp

  Line 108 in ce5ca74

  std::string ExtAPI::getExtBcPath()

1. it crashes when none of the conditions hold
2. instead of "echo $SVF_DIR" it should just use getenv
3. consider adding a setExtBcPath function for a simplified API¹
4. there is a typo "extaib" in the error message
5. EXTAPI_PATH is defined based on the source directory, imho that should be the installation directory
   

   SVF/.config.in

   Line 4 in ce5ca74

   #define PROJECT_PATH "@CMAKE_CURRENT_SOURCE_DIR@"

---

¹ path is now unused in:

SVF/svf/lib/Util/ExtAPI.cpp

Line 38 in c0dac77

ExtAPI* ExtAPI::getExtAPI(const std::string& path)

?

[yuleisui]

Thanks for reporting. Except for gcc 13.2.1, could you please help with a pull request to fix the other issues first?

[yuleisui]

For the gcc 13.2.1 compilation error, could we fix the code rather than changing the compiler option?

[251]

Sorry, but at the moment I don't have the time to fix it. Maybe @shuangxiangkan can help with the ExtAPI implementation? The gcc issue is caused by the overloading of the virtual operators in the Abstract Execution module:

In file included from /tmp/SVF/svf/include/AbstractExecution/ConsExeState.h:30,
                 from /tmp/SVF/svf/lib/AbstractExecution/ConsExeState.cpp:29:
/tmp/SVF/svf/include/AbstractExecution/ExeState.h:93:18: error: ‘virtual bool SVF::ExeState::operator==(const SVF::ExeState&) const’ was hidden [-Werror=overloaded-virtual=]
   93 |     virtual bool operator==(const ExeState &rhs) const;
      |                  ^~~~~~~~
/tmp/SVF/svf/include/AbstractExecution/ConsExeState.h:104:10: note:   by ‘bool SVF::ConsExeState::operator==(const SVF::ConsExeState&) const’
  104 |     bool operator==(const ConsExeState &rhs) const;
      |          ^~~~~~~~
/tmp/SVF/svf/include/AbstractExecution/ExeState.h:95:25: error: ‘virtual bool SVF::ExeState::operator!=(const SVF::ExeState&) const’ was hidden [-Werror=overloaded-virtual=]
   95 |     inline virtual bool operator!=(const ExeState &rhs) const
      |                         ^~~~~~~~
/tmp/SVF/svf/include/AbstractExecution/ConsExeState.h:106:10: note:   by ‘bool SVF::ConsExeState::operator!=(const SVF::ConsExeState&) const’
  106 |     bool operator!=(const ConsExeState &other) const
      |          ^~~~~~~~
cc1plus: all warnings being treated as errors

[yuleisui]

Thanks, @shuangxiangkan could you please fix the issue mention above?

[251]

There is another issue with the extapi handling:

SVF/svf/lib/Util/Options.cpp

Line 776 in ce5ca74

"extapi", "External API extapi.bc", ExtAPI::getExtAPI()->getExtBcPath()

Whenever one links SVF, it calls getExtBcPath() in the Option definition. That means when SVF (as a library) is used optionally, one still has to provide an extapi.bc and SVF executes for no reason. It also prevents the initialisation of SVF_DIR via setenv in a program as those flags are globally initialised before handing the execution over to main.

[yuleisui]

I see. Thanks for reporting this. @shuangxiangkan please have a look at this too

[yuleisui]

@251 please take a look at thi s fix: #1210

let us know if there is still an issue for compilation and crash.

[251]

Hi @yuleisui,

I had a look at the latest version. The build issues are fixed (besides the uncopied files), thanks for that. But there are still some issues with extapi.bc:

1. there is still no setter for the path
2. it still doesn't use getenv but spawns a shell unnecessarily
3. even when I try to hack around it by setting SVF_DIR, it always appends EXTAPI_BC_PATH (Release-build/svf-llvm/extapi.bc), which does not exist on my machine

SVF/svf/lib/Util/ExtAPI.cpp

Line 103 in 62e1cf4

bcFilePath.append(EXTAPI_BC_PATH);

SVF/svf/include/Util/ExtAPI.h

Line 41 in 62e1cf4

#define EXTAPI_BC_PATH "Release-build/svf-llvm/extapi.bc"

4. it still crashes when it can't find a path because the back() operation is unguarded (string is empty):

SVF/svf/lib/Util/ExtAPI.cpp

Line 101 in 62e1cf4

if (bcFilePath.back() != '/')

5. According to the error message some variables in .config.in are unresolved (SVF_IR_PATH, CMAKE_BUILD_TYPE).

No extapi.bc found at <dir>/node_modules/svf-lib/SVF-linux/Release-build/svf-llvm/extapi.bc for getExtAPI(); The default path for extapi.bc is: SVF_IR_PATH/CMAKE_BUILD_TYPE-build/svf-llvm/extapi.bc !

A simple getenv without any alterations to the path (suffix) would be a working fix for me.

[yuleisui]

I see. I think @shuangxiangkan should be able to fix it soon

[shuangxiangkan]

Hi, @251, thank you for your suggestions, I have some questions before I submit new pr,

1. there is still no setter for the path

In the next pr, the path to the user's own extapi.bc will be set using the -extapi=path_to_extapi command.

2. it still doesn't use getenv but spawns a shell unnecessarily

The reason for not using getenv() to handle SVF_DIR is that getFilePath() is used to handle both $SVF_DIR and npm root uniformly. Of course, using getenv(SVF_DIR) would be more appropriate, but it might require separate code for SVF_DIR and npm root. Which one do you think is better?

SVF/svf/lib/Util/ExtAPI.cpp

Line 81 in 62e1cf4

static std::string getFilePath(const std::string& path)

3. even when I try to hack around it by setting SVF_DIR, it always appends EXTAPI_BC_PATH (Release-build/svf-llvm/extapi.bc), which does not exist on my machine

You're right. If we are looking for extapi.bc through the $SVF_DIR, and it's in Debug mode, it should append Debug-build/svf-llvm/extapi.bc rather than Release-build/svf-llvm/extapi.bc . But I don't understand this:

A simple getenv without any alterations to the path (suffix) would be a working fix for me.

If you use getenv("SVF_DIR") without any suffix (e.g., "Debug-build/svf-llvm/extapi.bc"), SVF_DIR is just the build directory for SVF. SVF won't be able to locate extapi.bc.

Furthermore, could you provide further explanation for this ?

9. According to the error message some variables in .config.in are unresolved (SVF_IR_PATH, CMAKE_BUILD_TYPE).

No extapi.bc found at <dir>/node_modules/svf-lib/SVF-linux/Release-build/svf-llvm/extapi.bc for getExtAPI(); The default path for extapi.bc is: SVF_IR_PATH/CMAKE_BUILD_TYPE-build/svf-llvm/extapi.bc !

I'm not clear on how this error is produced.
In addition, I plan to add BUILD_TYPE to .config.in to ensure that using $SVF_DIR can find extapi.bc path(Debug mode or Release mode). What do you think?

#ifndef CONFIG_H_IN
#define CONFIG_H_IN

#define PROJECT_PATH "@CMAKE_CURRENT_SOURCE_DIR@"
#define BUILD_TYPE "@CMAKE_BUILD_TYPE@-build"
#define EXTAPI_DIR PROJECT_PATH "/@CMAKE_BUILD_TYPE@-build/svf-llvm"

#endif

[251]

Hi @shuangxiangkan, thanks for having a look at those issues.

In the next pr, the path to the user's own extapi.bc will be set using the -extapi=path_to_extapi command.

Sounds good but I'm also looking for something like setExtBcPath("path/extapi.bc") to set the path to extapi.bc via API.

Of course, using getenv(SVF_DIR) would be more appropriate, but it might require separate code for SVF_DIR and npm root. Which one do you think is better?

The getenv version because it's much simpler for that case. Also, I think there is a performance penalty. The path is not stored and getExtBcPath is called a lot (e.g. in isCalledExtFunction) and reexecutes all the time (I have several thousand syscalls to fstatat in the strace dump). It just makes no sense to spawn thousands of shells. ExtAPI would benefit quite a lot from storing the path once (also simplifies the setter above) and just handing out that path instead of trying to find extapi.bc all the time.

You're right. If we are looking for extapi.bc through the $SVF_DIR, and it's in Debug mode, it should append Debug-build/svf-llvm/extapi.bc rather than Release-build/svf-llvm/extapi.bc . But I don't understand this:

A simple getenv without any alterations to the path (suffix) would be a working fix for me.

That wouldn't work either, because there is no src/build directory on my machine, I just use the installation directory. What I meant is:

$ SVF_DIR=/path/my_extapi.bc wpa ...

or

$ SVF_DIR=/path/ wpa ...

should work without appending suffixes such as Debug-build/svf-llvm/ to $SVF_DIR internally.

I'm not clear on how this error is produced.

Ah, sorry. I was confused about the error message (+ there is a plenk at the end):

The default path for extapi.bc is: SVF_IR_PATH/CMAKE_BUILD_TYPE-build/svf-llvm/extapi.bc !

I thought SVF_IR_PATH/CMAKE_BUILD_TYPE is supposed to be replaced at compile time to the actual location.

I plan to add BUILD_TYPE to .config.in to ensure that using $SVF_DIR can find extapi.bc path(Debug mode or Release mode). What do you think?

No hard feelings about that one because this is not how I use SVF. I install SVF roughly similar to:

/build/svf$ cmake -DCMAKE_INSTALL_PREFIX=/my_root -DSVF_ENABLE_ASSERTIONS:BOOL=true -DCMAKE_BUILD_TYPE=Debug -DLLVM_DIR=/my_root/lib/cmake/llvm -DZ3_INCLUDES=/my_root/include -DZ3_LIBRARIES=/muy_root/lib/libz3.so /src/SVF
/build/svf$ make -j4 && make install
/build/svf$ cp svf/libSvfCore.a /my_root/lib
/build/svf$ cp include/Util/config.h /my_root/include/svf/Util
/build/svf$ cp svf-llvm/lib/extapi.c /my_root/data/my_extapi.bc

[shuangxiangkan]

Hi, @251

Because you're not using SVF's default installation method (source ./build.sh), but instead opting for your own installation method,

I install SVF roughly similar to: ...

SVF encounters issues when attempting to find extapi.bc using the default installation method in getExtBcPath(). It seems like you want to locate extapi.bc by setting SVF_DIR as SVF_DIR=/path/my_extapi.bc.

That wouldn't work either, because there is no src/build directory on my machine, I just use the installation directory. What I meant is:

$ SVF_DIR=/path/my_extapi.bc wpa ...

or

$ SVF_DIR=/path/ wpa ...

should work without appending suffixes such as Debug-build/svf-llvm/ to $SVF_DIR internally.

However, typically SVF_DIR refers to the installation directory of SVF (SVF_DIR=/path_to_SVF), not the directory where extapi.bc is located. So I think it would be more reasonable to use setExtBcPath() in a custom SVF installation method to set the path for extapi.bc, rather than relying on SVF_DIR.

[shuangxiangkan]

PR #1212 provides two ways to specify extapi.bc path:
1. Set it via the command line using -extapi=/path_to_extapi;
2. Use the API setExtBcPath(). Please note that setExtBcPath() should be used before buildSVFModule().

You can try this pr, and if there are any further issues, please let me know.

[251]

Because you're not using SVF's default installation method (source ./build.sh), but instead opting for your own installation method

The thing is, build.sh is not really an "installation method". If I remember correctly, it just treats the build directory with all its leftovers as installation directory.

PR #1212 provides two ways to specify extapi.bc path

Thanks, I added two comments.