This is another unexpected result of eac236ea7bfc1902126be70459e320591078df5c,
which happens often when bisecting between v1.3.0 and current git master.
Before the said commit, trace.c and trace.h files were generated in the
build dir. Now trace.c has moved to include/trace.h and it acts just
as a redirector to generated-tracers.h. But due to -I., current dir
is searched first.
So, when bisection crosses this commit, we have old trace.h floating
around, and it gets included by subsequent compiles, instead of the
newly introduced include/trace.h.
The result is a mess - failing compiles basically, and it isn't obvious
how to fix.
To fix, one have to remove trace.h *and* all .o (and .d) files which
included (mentions) it, and re-run make to rebuild them with proper
trace.h.
I'm not sure how to fix this best. One approach is something like this:
--- a/trace/Makefile.objs
+++ b/trace/Makefile.objs
@@ -9,6 +9,8 @@ $(obj)/generated-tracers.h-timestamp: $(SRC_PATH)/trace-events
$(BUILD_DIR)/conf
--format=h \
--backend=$(TRACE_BACKEND) \
< $< > $@," GEN $(patsubst %-timestamp,%,$@)")
+# remove old (from qemu 1.3 and before) autogenerated trace files
+ @rm -f ../trace.[chd] ../trace.h ../trace.[ch]-timestamp
@cmp -s $@ $(patsubst %-timestamp,%,$@) || cp $@ $(patsubst
%-timestamp,%,$@)
######################################################################
Ie, just remove the possible remnants when (re)generating generated-tracers.h.
This is disgusting obviously.
There's another approach: rename trace.h into, say, qemu-trace.h, so
old, no-longer-used-but-staying-on-the-way, trace.h will not be included
anymore.
And there's 3rd: just ignore this issue, since we can't improve git
bisectability between 1.3 and 1.4 already, and it will be bisectable
again past 1.4 (without new issues of the same sort).
Oh well.
/mjt
