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

Unsound bitcode collection when a single file is compiled multiple times #58

Open
woodruffw opened this issue Mar 2, 2022 · 4 comments

Comments

@woodruffw
Copy link
Collaborator

GLLVM doesn't currently distinguish between multiple compilations of the same input file in a single build. For example, imagine the following:

all: foo.exe foo.patched.exe

%.exe: $(SRC_DIR)/%.c
	mkdir -p $(dir $@)
	$(CC) $(CFLAGS) -o $@ $^

%.patched.exe: $(SRC_DIR)/%.c
	mkdir -p $(dir $@)
	$(CC) $(CFLAGS) -DPATCHED=1 -o $@ $^

When make all is run, foo.c is compiled twice: once with -DPATCHED=1 and once without.

GLLVM however only produces only one .foo.c.{o,bc} tuple, meaning that the get-bc-collected bitcode for both foo.exe and foo.patched.exe is the same (whichever target make ran last).

I think the solution here is to rewrite GLLVM's object and bitcode file emission to use content-addressed filenames, rather than path-computed filenames.

@woodruffw
Copy link
Collaborator Author

GLLVM however only produces only one .foo.c.{o,bc} tuple, meaning that the get-bc-collected bitcode for both foo.exe and foo.patched.exe is the same (whichever target make ran last).

To be more precise: GLLVM actually produces two tuples, but clobbers the first (the foo.exe one) with the second (foo.patched.exe).

@ianamason
Copy link
Member

I wonder if we can please all of the build systems all of the time. If the output was called foo_patched rather than
foo.patched, we'd be OK, right?

@woodruffw
Copy link
Collaborator Author

I wonder if we can please all of the build systems all of the time. If the output was called foo_patched rather than
foo.patched, we'd be OK, right?

I'm not 100% sure -- I think the confusion happens with the source files, since GLLVM special-cases the "single" compilation mode and will clobber .foo.c.o and .foo.c.bc regardless of the output target.

woodruffw added a commit to woodruffw-forks/gllvm that referenced this issue Mar 2, 2022
@ianamason
Copy link
Member

Yeah you are right.

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

No branches or pull requests

2 participants