DynamoRIO / DynamoRIO/dynamorio

DR config removes /Zi from standalone executable w/ VS generator

Open
#1,357 0 comments 0 reactions 0 assignees View on GitHub
Component-Build Hotlist-Release Migrated OpSys-Windows Priority-Medium
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 15h
Merged PRs (30d)
31

Description

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on February 04, 2014 12:21:30_

Sample from user sent to users list:

```
cmake_minimum_required (VERSION 2.8)
project(poc)
find_package(DynamoRIO REQUIRED)
add_executable(poc main.cc)
configure_DynamoRIO_standalone(poc)

#include "dr_api.h"
#include
int main(int argc, char\* argv[]) {
void\* dr_context = dr_standalone_init();
printf("Hello from standalone tool!\n");
return 0;
}
```

```
cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DDynamoRIO_DIR:PATH=d:/derek/dr/git/exports/cmake ..
```
=>
there is /Zi

```
cmake -DCMAKE_BUILD_TYPE=Debug -DDynamoRIO_DIR:PATH=d:/derek/dr/git/exports/cmake ..
dclick poc.vcxproj
```
=>
no /Zi listed in C/C++ General tab

Remove find_package and configure_DynamoRIO_standalone
=>
/Zi is listed

Make this change in configure_DynamoRIO_standalone():
```
set(CLIENT_${var} "${CLIENT_${var}}" PARENT_SCOPE)
# set(${var} "${${var}}" PARENT_SCOPE)
```

and now /Zi is there.

But how do we safely do that if a project has a client as well as a
standalone target? Rely on the user to read the top of
DynamoRIOConfig.cmake and set back to ORIG on their own if they have no
client?

Maybe the /Zi problem is a simpler one: maybe it's related to the /debug
link flag disappearing. Perhaps we can keep both of those and solve this
for clients too that way.

To check: does /Zi go away for clients too?

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1357_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.