Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blacklist executables #320

Open
smhc opened this issue Nov 2, 2020 · 2 comments
Open

Blacklist executables #320

smhc opened this issue Nov 2, 2020 · 2 comments

Comments

@smhc
Copy link
Contributor

smhc commented Nov 2, 2020

Describe the bug
Some executables are problematic with LD_PRELOAD and will log errors (or potentially fail?). This can be avoided by using the wrapper compilers, or avoiding using bear for those exectuables, but the ability to blacklist them would be easier.

To Reproduce
The 'wine' executable cannot use the LD_PRELOAD system. If your build uses wine and a windows compiler as part of the build there will be excessive errors. e.g

$ bear -- wine
ERROR: ld.so: object '/../bear/rel/libexec.so' from LD_PRELOAD cannot be preloaded: ignored.
Usage: wine PROGRAM [ARGUMENTS...]   Run the specified program
       wine --help                   Display this help and exit
       wine --version                Output version information and exit

Expected behavior
The LD_PRELOAD should not be set for exectuables that have known problems, or explicitly listed as being problematic. This could also be used to avoid processing large parts of a build that are not expected to perform c/c++ compilation.

Environment:

  • OS name: Linux
  • OS version: Oracle Linux 7
  • OS architecture: x86_64
  • Bear version: 3.0.0
  • Bear install method: build

Additional context

  • Can you give us a reference to the project that you are running against this tool?No
  • What build tools this project is using? make, wine, gcc, perl, cl
  • What architecture you are trying to compile for? Linux and Windows

Before you send...

  • Have you read the README.md file or man bear? Y
  • Have you looked what other open issues Bear has? Y
  • Are you sure that the build works without Bear? Y
@rizsotto
Copy link
Owner

rizsotto commented Nov 2, 2020

Hey @smhc , thanks for the extensive testing of this tool. I really appreciate it!

As far as I know, wine is a 32 bit executable. And the dynamic linker error message is about that you want to LD_PRELOAD a 64 bit library. This was a known issue with the earlier releases. And there was a recipe to build both 32bit and 64bit libraries and use the one which is appropriate... The 3.0 series is not that mature yet.

I would re-phrase this ticket as "support multilib builds". (Or we can create a new ticket.)

But I am interested how is your build would work? Is it calling wine in the middle of the build? And compiles some source files to Windows and then it continues on Linux?

And I am also interested how would you imagine to stop intercepting the command executions in the middle of the build. Are we talking about a call like bear --ignore wine --ignore python -- make which will stop tracing the command executions before wine or python is called, but continues when they are finished?

@smhc
Copy link
Contributor Author

smhc commented Nov 2, 2020

I have a build script that compiles many projects in parallel. It uses make/gcc to compile 64bit Linux binaries, but it also calls wine to run a Windows compiler to compile Windows exectuables. I use bear on this top level wrapper script and it augments all the compilation appropriately. I could call bear separately for each module and skip the wine projects - however there would be a lot of contention given that the modules are built in parallel.

Ideally I'd like to tell bear not to use LD_PRELOAD when compiling those problematic modules - or alternatively, blacklist particular executable names.

And I am also interested how would you imagine to stop intercepting the command executions in the middle of the build. Are we talking about a call like bear --ignore wine --ignore python -- make which will stop tracing the command executions before wine or python is called, but continues when they are finished?

Yes something like that. However it doesn't need to 'stop' and 'resume'. It just needs to not add the LD_PRELOAD env variable when starting a new exectuable of an ignored name. Obviously you would lose the ability to hook exec calls from that point onwards in that process tree - but I think that is desired behaviour.

I envision this line:

auto environment = update(environment_);

would have an if condition to remove the LD_PRELOAD environment variable rather than add it in when it matches a particular exe name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants