Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
@ 2002-12-28  1:00 Nathanael Nerode
  2002-12-28  1:22 ` Alexandre Oliva
                   ` (2 more replies)
  0 siblings, 3 replies; 29+ messages in thread
From: Nathanael Nerode @ 2002-12-28  1:00 UTC (permalink / raw)
  To: gcc-patches, gdb-patches, binutils, kazu

I can't reproduce exactly the problem you had, Kazu, but I did manage to
generate some dramatic breakage; apparently autoconf's version of
$program_transform_name doesn't like to be after the s/x/x/ in sed.
Luckily, autoconf's version of $program_transform_name is s/x/x if it would
otherwise be blank, so we can just delete the extra s/x/x.

Does this fix it?
(If you don't have autogen, this patch is the same for Makefile.tpl and 
Makefile.in, so just apply it to each.)


	* Makefile.tpl: Fix dramatic bustage due to change in
	program_transform_name.
	* Makefile.in: Regenerate.

Index: Makefile.tpl
===================================================================
RCS file: /cvs/gcc/gcc/Makefile.tpl,v
retrieving revision 1.24
diff -u -r1.24 Makefile.tpl
--- Makefile.tpl	28 Dec 2002 06:57:48 -0000	1.24
+++ Makefile.tpl	28 Dec 2002 08:21:15 -0000
@@ -282,7 +282,7 @@
     if [ '$(host_canonical)' = '$(target_canonical)' ] ; then \
       echo $(AS); \
     else \
-       t='$(program_transform_name)'; echo as | sed -e 's/x/x/' $$t ; \
+       t='$(program_transform_name)'; echo as | sed -e $$t ; \
     fi; \
   fi`
 
@@ -296,7 +296,7 @@
     if [ '$(host_canonical)' = '$(target_canonical)' ] ; then \
       echo $(LD); \
     else \
-       t='$(program_transform_name)'; echo ld | sed -e 's/x/x/' $$t ; \
+       t='$(program_transform_name)'; echo ld | sed -e $$t ; \
     fi; \
   fi`
 
@@ -308,7 +308,7 @@
     if [ '$(host_canonical)' = '$(target_canonical)' ] ; then \
       echo $(DLLTOOL); \
     else \
-       t='$(program_transform_name)'; echo dlltool | sed -e 's/x/x/' $$t ; \
+       t='$(program_transform_name)'; echo dlltool | sed -e $$t ; \
     fi; \
   fi`
 
@@ -320,7 +320,7 @@
     if [ '$(host_canonical)' = '$(target_canonical)' ] ; then \
       echo $(WINDRES); \
     else \
-       t='$(program_transform_name)'; echo windres | sed -e 's/x/x/' $$t ; \
+       t='$(program_transform_name)'; echo windres | sed -e $$t ; \
     fi; \
   fi`
 
@@ -332,7 +332,7 @@
     if [ '$(host_canonical)' = '$(target_canonical)' ] ; then \
       echo $(AR); \
     else \
-       t='$(program_transform_name)'; echo ar | sed -e 's/x/x/' $$t ; \
+       t='$(program_transform_name)'; echo ar | sed -e $$t ; \
     fi; \
   fi`
 
@@ -348,7 +348,7 @@
          echo ranlib; \
       fi; \
     else \
-       t='$(program_transform_name)'; echo ranlib | sed -e 's/x/x/' $$t ; \
+       t='$(program_transform_name)'; echo ranlib | sed -e $$t ; \
     fi; \
   fi`
 
@@ -362,7 +362,7 @@
     if [ '$(host_canonical)' = '$(target_canonical)' ] ; then \
       echo $(NM); \
     else \
-       t='$(program_transform_name)'; echo nm | sed -e 's/x/x/' $$t ; \
+       t='$(program_transform_name)'; echo nm | sed -e $$t ; \
     fi; \
   fi`
 


^ permalink raw reply	[flat|nested] 29+ messages in thread
* Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
@ 2002-12-28  4:36 Nathanael Nerode
  2002-12-28  8:33 ` Alexandre Oliva
  2002-12-28 11:00 ` DJ Delorie
  0 siblings, 2 replies; 29+ messages in thread
From: Nathanael Nerode @ 2002-12-28  4:36 UTC (permalink / raw)
  To: gcc-patches; +Cc: gdb-patches, binutils, kazu, aoliva

Alex pointed out:
>This unfortunately means that your fix is not quite perfect yet, since
>multiple transform commands would be word-split and sed might take
>them as input file names.  I suggest replacing:
>
>        t='$(program_transform_name)'; echo as | sed -e $$t ; \
>
>with
>
>        echo as | sed '$(program_transform_name)'; \
>
>that is the construct used by automake.

Unfortunately, I really have to go to sleep now. :-(  And I have to 
focus my mind on other things for a few days, too.

Please feel free to make this change on your own; it's obviously 
correct as far as I'm concerned.

And likewise to anyone else who wants to improve the top level;
now that autoconfiscation, and configure-on-demand, have actually 
happened, I just don't need the tight control on the top level files 
which I was exercising before.  (At least until I start on the new build 
scheme, which won't be for a while.)  

Part of the motivation for autoconfiscating was to make the top level less 
of a "secret region" which only the "initiated" could hack on.  I hope 
I've accomplished that.

--Nathanael


^ permalink raw reply	[flat|nested] 29+ messages in thread
* Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
@ 2002-12-28 13:22 Michael Elizabeth Chastain
  2002-12-28 13:44 ` Alexandre Oliva
  2003-01-06  0:04 ` Ben Elliston
  0 siblings, 2 replies; 29+ messages in thread
From: Michael Elizabeth Chastain @ 2002-12-28 13:22 UTC (permalink / raw)
  To: aoliva, dj; +Cc: binutils, drow, gcc-patches, gdb-patches

My two cents:

To me, a race is a race.  Just don't have them in the first place and no
bugs will creep in.

I would also prefer no locks, because I don't want to deal with locking
mechanism headaches when a user with, say, an SMP Irix NFS client and
an HP/UX NFS server has funny build problems.

So I'm in favor of a dumb, simple, and reliable mechanism to serialize
the configures.

Michael C


^ permalink raw reply	[flat|nested] 29+ messages in thread
* Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
@ 2002-12-29  0:39 Michael Elizabeth Chastain
  2002-12-29  2:48 ` Alexandre Oliva
  0 siblings, 1 reply; 29+ messages in thread
From: Michael Elizabeth Chastain @ 2002-12-29  0:39 UTC (permalink / raw)
  To: aoliva; +Cc: binutils, dj, drow, gcc-patches, gdb-patches

Alexandre Oliva writes:
> Should we penalize everybody just because some might want to make -j
> and make it absolutely sure that they won't have any risk whatsoever
> of cache corruption and they won't miss any opportunities for caching
> test results.

In my humble opinion, yes.  If you have a choice of options,
make the default option be safe, and let people who want to go faster
with risk of corruption specify additional options.

Perhaps you think of "make -j" as an inherently unsafe option.
In 1999 I would have agreed.  In 2002 I think it's debatable.
As time passes, I think it will become more and more important
that it work without races.

I build gcc about 50 times per week with automated scripts.  Right now
I use a single-processor machine.  If I buy a multi-processor machine,
I would like to just turn on "make -j" and have it work.  When it doesn't
work, I want all the bugs that I see to be real bugs that I can report
to gcc-bugs and not have to check for cache corruption on every fail and
not have people closing my bug reports with "might be cache corruption,
don't use -j".

I know other people run automated and semi-automated builds, too.

> Couldn't we instead ask these to pass an argument to configure such that
> will make sure their requirements are satisfied, while optimizing for
> most who aren't doing parallel builds, or can take the negligible risk of
> cache corruption, or don't care about potential loss of sharing of cache
> results, but who want to benefit from the ability to configure only the
> packages that matter for them.  Are we really doing the right trade off?

I agree that this is a trade-off.  Obviously we disagree about what the
right trade-off is.

I think I've aired my viewpoint enough (it's kind of a simple view)
so I'll rest here.

Michael C


^ permalink raw reply	[flat|nested] 29+ messages in thread
* Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
@ 2003-01-06  0:49 Michael Elizabeth Chastain
  0 siblings, 0 replies; 29+ messages in thread
From: Michael Elizabeth Chastain @ 2003-01-06  0:49 UTC (permalink / raw)
  To: bje, gdb-patches; +Cc: binutils, gcc-patches

Ben Elliston writes:
> If, instead, the cache were a "dot" directory that contained files
> whose filenames had the form "key=value", then test results could be
> examined or updated using atomic file system operations and there
> should be no races.

The Linux kernel does something similar for its configuration variables
(which are different than autoconf cache entries): one file per variable.
The kernel does this to achieve fine-grained dependencies on the
configuration, so that changing CONFIG_DRIVER_FOO causes recompilation
of only the files that depend on CONFIG_DRIVER_FOO.

With a little care I think this would be thread safe.  One tricky point
is that you have to be prepared for a file to not exist at the moment
you open it because some other thread is doing an "unlink / rename" at
that moment.  Since this is a cache, that will simply cause some extra
cache misses.

There is a potential for a thundering-herd performance problem where every
thread wants to compute HAVE_FOO_H, they all deposit identical copies into
the cache, and then they move on and see that HAVE_BAR_H is not in the
cache either, lockstepping their way through similar configure scripts.
It would actually improve efficiency for autoconf to randomize the order
of tests in the configure script.  :)

Also, I think that you could mix the two cache styles in a single tree.
All the old-style subdirectories would use config.cache, and all
the new-style subdirectories would use the new fine-grained cache.
Serialization would be needed only for old-style "config.cache"
subdirectories.  New-style subdirectories could somehow say to autogen
"I am new-style, I use the new fine-grained cache, don't serialize my
configure goal with other configure goals."  There would be a performance
penalty for a mixed tree, which would go away when the last old-style
subdirectory got upgraded.

Michael C
back-seat driver :)


^ permalink raw reply	[flat|nested] 29+ messages in thread
end of thread, other threads:[~2003-01-06  0:49 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-28  1:00 (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name) Nathanael Nerode
2002-12-28  1:22 ` Alexandre Oliva
2002-12-28  1:33 ` Alexandre Oliva
2002-12-28  7:47 ` Kazu Hirata
2002-12-28  4:36 Nathanael Nerode
2002-12-28  8:33 ` Alexandre Oliva
2002-12-28  9:51   ` Daniel Jacobowitz
2002-12-28  9:56     ` Alexandre Oliva
2002-12-28  9:59       ` Daniel Jacobowitz
2002-12-28 10:41         ` Alexandre Oliva
2002-12-28 10:46           ` Dan Kegel
2002-12-28 11:07             ` DJ Delorie
2002-12-28 12:26               ` Daniel Jacobowitz
2002-12-28 10:50           ` Daniel Jacobowitz
2002-12-28 11:01             ` DJ Delorie
2002-12-28 12:57               ` Alexandre Oliva
2002-12-28 13:51                 ` Alexandre Oliva
2002-12-29 18:57                   ` Alexandre Oliva
2002-12-28 14:14                 ` DJ Delorie
2002-12-28 15:22                   ` Alexandre Oliva
2002-12-28 10:54           ` Alexandre Oliva
2002-12-28 10:49       ` DJ Delorie
2002-12-28 11:00 ` DJ Delorie
2002-12-28 13:22 Michael Elizabeth Chastain
2002-12-28 13:44 ` Alexandre Oliva
2003-01-06  0:04 ` Ben Elliston
2002-12-29  0:39 Michael Elizabeth Chastain
2002-12-29  2:48 ` Alexandre Oliva
2003-01-06  0:49 Michael Elizabeth Chastain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox