X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Thu, 8 Apr 1999 17:44:14 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: Gurunandan R Bhat <grbhat AT unigoa DOT ernet DOT in>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Can (was Re: Cannot) build linux-x-dos cross-compiler
In-Reply-To: <Pine.LNX.4.04.9904081553480.27805-100000@aditya.unigoa.ernet.in>
Message-ID: <Pine.LNX.3.93.990408171811.200Y-100000@acp3bf>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Thu, 8 Apr 1999, Gurunandan R Bhat wrote:
> On Thu, 8 Apr 1999, Hans-Bernhard Broeker wrote:
> > > On Sun, 4 Apr 1999, Gurunandan R Bhat wrote:

> > > > 1. ldscripts are incorrectly built if I use bash2.0 (on SuSE 5.3). The
> > > >    genscripts.sh adds multiple braces. I solved this by reverting back to
> > > >    bash1.
> 
> > but the real bug is in the script that generates the ldscripts. I
> > can't remember the details off-hand, but I recall my conclusion at the
> > time to have been that the ldscript generator, a sh script, only ever
> > worked because bash *1* had a bug in its handling of nested
> > ${var:value} constructs containing additional '{' or '}' characters.
> 
> The script is simple enough and the bug there was not obviously clear to
> me. For example, both bash versions produce the correct scripts (atleast
> as far as matching braces are concerned) for other i386 formats in the
> template subdirectory. I am currently building bash-2.03 to see what
> happens and will keep you posted.

I just managed to reproduce the bug, using yet another shell (Digital Unix
/bin/sh, on an Alpha box). I spotted the offending lines I remembered, as
well. They're in binutils-2.9.1/ld/scripttempl/i386go32.sc, and look like
this: 

  ${CONSTRUCTING+${RELOCATING-.ctor : { *(.ctor) }}}
  ${CONSTRUCTING+${RELOCATING-.dtor : { *(.dtor) }}}

The problem is that inside the pairing of {}. Bash 1 (incorrectly) parsed
this fragment as

  ${
    CONSTRUCTING+
    ${
      RELOCATING-
      .ctor : { *(.ctor) }
     }
   }

which evaluates to nothing, for some of the scripts.  Bash 2, and the
Digital Unix shell parse it as: 

  ${
    CONSTRUCTING+
    ${
      RELOCATING-
      .ctor : { *(.ctor)
     }
   }
  }

The final '}' is left sitting there, leading to linker scripts with two
unpaired '}' in those cases where bash 1 evaluated to nothing. A simpler
test case that shows the difference more clearly is:

	echo "${FOO-{B}C}"

where FOO is not an existing variable. bash version 1 echoes '{B}C' for
this, whereas Digital's /bin/sh gives '{BC}'. The behaviour of Digital's
/bin/sh is reproducible with all shells I tried, except for bash 1. Bash 1
seems to incorrectly parse for '{}' pairs in the 'word' after the '-' in
'${parameter-word}' expressions. 

Looking at the stored ldscripts (they're in 'ld/ldscripts' in the binutils
build tree), it seems the problem effects all the linker scripts,
actually, except for the '.xu' one. The scripts built into the cross-ld
are effected, too. 


Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.