raytheonbbn / weldr Goto Github PK

Describe the bug
The --model-dir flag defaults to a hard-coded absolute path, meaning that weldr will try looking for its resources in a directory that probably doesn't exist.

To Reproduce
Run weldr without using the --model-dir/-M flag, with weldr installed in any directory other than /home/test/bwam-installer/weldr. It will quit with errors due to missing files.

Expected behavior
The default value for the flag should reference the directory into which the weldr repository was checked out.

Additional context
As of Jun. 23, 2020, the specific bug is in weldr/main.py line 17, where the --model-dir flag gets added to the argument parser.

Example Project
N/A; any attempt to execute weldr will trip this.

Describe the bug
If -t is specified as a relative path, the torch command files generated in deconflict_syms reference their target file with an incorrect relative path. Specifically, the path will be relative to the child of the current directory, instead of the current directory itself.

To Reproduce
Run any weldr project with -t specified as a relative path (with or without a leading dot).

Expected behavior
Weldr should use a consistent current directory for relative paths.

Additional context
N/A

Example Project
N/A; this is project-independent.

Hi, I was added to https://pldi21.sigplan.org/details/SOAP-2021-papers/3/Weldr-Fusing-Binaries-for-Simplified-Analysis but have no affiliation with this project.

Describe the bug
Weldr defaults to using static library models. However, this feature wasn't fully re-implemented after the major changes needed to support dynamic modeling.

To Reproduce
Execute weldr without the -D flag.

Expected behavior
At the very least, switch the behavior to use dynamic modeling by default, and raise an error if you try to use static.

Additional context
Static modeling support is a very low priority for the weldr team. It's useful if your analyzer doesn't support dynamic loading, but it can only weld projects that have an option to be compiled statically.

Example Project
N/A

Describe the bug
fake_pthread/fake_setjmp.S does not link correctly when compiling libwrap_pthread.so on Ubuntu 18.04. ld reports the following relocation error:

/usr/bin/ld: bin/fake_setjmp.pic.oS: relocation R_X86_64_PC32 against symbol `sigprocmask@@GLIBC_2.2.5'
 can not be used when making a shared object; recompile with -fPIC

To Reproduce
With Weldr installed in an Ubuntu 18.04 environment, perform the folllowing steps:

• cd <repository root>/fake_pthread
• make clean all

Expected behavior
libwrap_pthread.so should build and link correctly.

Additional context
I'm not sure if this is specific to Ubuntu 18.04.

The file fake_setjmp.S doesn't use sigprocmask, nor does its header, fake_setjmp.h. The header includes the global header setjmp.h, because it needs the jmpbuf type. It may be coming from there, indicating a library version mismatch. Why this is interfering with PIC relocation, I don't know.

Example Project
N/A; this is project-independent.

Describe the bug
Though weldr outputs a success message after compiling, the run_me binary segmentation faults right after Starting stub libraries. From the log file, the debug information shows that ELFStrItem is missing a method named resolve_references. The error location can be inferred that the fake_* directories have been built wrongly.

To Reproduce
make clean all on the fake_* directories with Makefile. Then, running make && weldr -s definition.sys -t <path to build location> <path to project location> on the example projects within this repo, and running run_me in the build location

Additional context
Though the README in the repo details the installation of weldr, it does not show any example usages of weldr in terms of building a project. It is possible that I myself have built the project wrongly, where I have used the command weldr -s definition.sys -t <path to build location> <path to project location>.

Upon debugging run_me and following its execution trace, the extrn function <local function>_weldr_init_stub_fake_stdio() called will error and kill the process. The project has been built multiple times and all built run_me segmentation faults. None of the repository code has been changed either. Is the stub table built correctly from the logs?
run.log

Example Project
The example projects within weldr.