Recent v2 abuild breakage

[Carl-Daniel Hailfinger]

Hi!

The recent v2 abuild breakage we're seeing since the move to a new
massively multiprocessor server may have been caused way back by r3564.
AFAICS it seems the dependency rules on romcc cause it to be compiled
twice if certain race conditions happen.
The v2 build system is sort of a mystery to me, so the following may or
may not work. I think I can fix this by compiling romcc into a temp file
and moving the temp file in the right place afterwards. That makes sure
no two compiler processes try to output to the same file at the same
time and it also makes sure that the romcc binary will always be runnable.

Any hints or better fixes are appreciated.

Regards,
Carl-Daniel

[Carl-Daniel Hailfinger]

On 16.10.2008 12:16, Carl-Daniel Hailfinger wrote:
> Hi!
>
> The recent v2 abuild breakage we're seeing since the move to a new
> massively multiprocessor server may have been caused way back by r3564.
> AFAICS it seems the dependency rules on romcc cause it to be compiled
> twice if certain race conditions happen.
> The v2 build system is sort of a mystery to me, so the following may or
> may not work. I think I can fix this by compiling romcc into a temp file
> and moving the temp file in the right place afterwards. That makes sure
> no two compiler processes try to output to the same file at the same
> time and it also makes sure that the romcc binary will always be runnable.
>
> Any hints or better fixes are appreciated.

This should fix it.
Can we PLEASE kill v2 ASAP? Thanks!

Signed-off-by: Carl-Daniel Hailfinger

Index: LinuxBIOSv2-tmp2/src/config/Config.lb
===================================================================
--- LinuxBIOSv2-tmp2/src/config/Config.lb	(Revision 3659)
+++ LinuxBIOSv2-tmp2/src/config/Config.lb	(Arbeitskopie)
@@ -162,9 +162,16 @@
    action	"doxygen corebootDoc.config"
 end

+# Yes, the rule doesn't seem to make sense, but multiple images could try to
+# create a romcc binary at the same time, clobbering each other.
+# Our makefile architecture won't allow us to easily have the romcc target
+# in the main makefile, so keep it here and move the race condition winner
+# in place. That way, romcc may get compiled twice, but the binary will always
+# be in a correct and valid state if it exists because the move is atomic.
 makerule ../romcc   
    depends	"$(TOP)/util/romcc/romcc.c" 
-	action	"$(HOSTCC) -g $(HOSTCFLAGS) $< -o $@"
+	action	"$(HOSTCC) -g $(HOSTCFLAGS) $< -o romcc.tmpfile"
+	action	"mv romcc.tmpfile $@"
 end

makerule build_opt_tbl

[ron minnich]

On Thu, Oct 16, 2008 at 7:05 AM, Carl-Daniel Hailfinger
 wrote:
> This should fix it.
> Can we PLEASE kill v2 ASAP? Thanks!
>
> Signed-off-by: Carl-Daniel Hailfinger

actually, thanks to you, corey, miles, marc, and a few others, we are
closer than ever.

ron

[Carl-Daniel Hailfinger]

On 16.10.2008 17:39, ron minnich wrote:
> On Thu, Oct 16, 2008 at 7:05 AM, Carl-Daniel Hailfinger wrote:
> > Can we PLEASE kill v2 ASAP? Thanks!
>
> actually, thanks to you, corey, miles, marc, and a few others, we are
> closer than ever.

We'd be nowhere if you weren't leading by example. Thanks a lot for all
the work you put in!

Regards,
Carl-Daniel

[Peter Stuge]

Carl-Daniel Hailfinger wrote:
> This should fix it.
>
> Signed-off-by: Carl-Daniel Hailfinger

Maybe just move romcc to util? Meanwhile;

Acked-by: Peter Stuge