other/869: Cross-compiled cross-assembler causes coredump

[jfaith@lineo.com]

>Number:         869
>Category:       other
>Synopsis:       Cross-compiled cross-assembler causes coredump
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 22 16:16:01 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     John Faith
>Release:        unknown-1.0
>Organization:
>Environment:
cywin 1.1.4 on win2k for running cross-assembler, Caldera
OpenLinux 2.3 for building all cross binutils/gcc's.
>Description:
On cygwin, the cross assembler dumps core when passed the
"--version" flag.

I am trying to build binutils 2.10 and gcc 2.95.2 which
will run on cygwin (host) and generate Linux binaries 
(target, build).  It looks like the "i586-cygwin32-"
cross tools are working correctly on Linux (and running 
on cygwin), and now I'm trying to build the
"i586-pc-linux-gnu-" binutils.

On Linux, binutils was configured with:
$ ../binutils-2.10/configure --host=i586-cygwin32 \
--target=i586-pc-linux-gnu --build=i586-pc-linux-gnu \
--prefix=/usr/local/bin-cyglin

I copied the resulting binutils executables to a MSWindows
machine and tried to run each with "--version" to verify
that I had valid executables.  All worked except for "as"
which dumped core.

Using the cygwin supplied gdb, I tracked the problem to a
single instruction in DCGETTEXT in 
binutils-2.10/intl/dcgettext.c (around line 248).

  ...
  /* First find matching binding.  */
  for (binding = _nl_domain_bindings; binding != NULL; binding = binding->next)
    {
      int compare = strcmp (domainname, binding->domainname);
  ...

Before the loop, binding=0x99 (uninitialized garbage), and
_nl_domain_bindings=0x0a0514c8.  After the loop
initialization, binding=0x6363636363.

The offending assembly instruction seems to be:
    mov %esi,%ds:0x4770fc
, where DS=0x23, and the variable "binding" is being kept
in the ESI register.  Memory looks like this:

0x4770fc    0x63636363 0x63636363 0x63636363 0x63636363
0x47710c    0x00000000 0x00000000 0x00000000 0x00000000
0x47711c    0x0a0514c8 0x00000000 0x00000000 0x00000000

Since = 0x23 + 0x4770fc = 0x47711f, it looks like the
correct code was generated, and that the assignment
should produce the desired 0x0a0514c8, assuming this is
how this type of addressing on the x86 is done.

The "linux-to-cygwin-gcc -v" gives:
gcc version 2.95.2 19991024 (release)

>How-To-Repeat:
tar -xf binutils-2.10.tar
tar -xf gcc-2.95.2.tar
mkdir binutils-lincyg ; cd binutils-lincyg
../binutils-2.10/configure --target=i586-cygwin32 \
--prefix=/usr/local/bin-lincyg
make all install
cd ..

mkdir gcc-lincyg ; cd gcc-lincyg
../gcc-2.95.2/configure --target=i586-cygwin32 \
 --prefix=/usr/local/bin-lincyg
make all install
cd ..

mkdir binutils-cyglin; cd binutils-cyglin
../binutils-2.10/configure --host=i586-cygwin32 \
--target=i586-pc-linux-gnu \
 --build=i586-pc-linux-gnu  --prefix=/usr/local/bin-cyglin
make all install
#Copy binutils to cygwin 1.1.4 machine and run
i586-pc-linux-as --version
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: