This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Cross compiled cross assembler dumps core


I'm curious if anyone can shed light on this problem.

I am trying to build binutils 2.10 and gcc 2.95.2 which will run on cygwin (host)
and generate Linux binaries (target).  I'm doing all building under Caldera Linux
2.3 (build).  I have built the "i586-cygwin32-" cross tools for Linux (and run a
"hello world" app 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 produced version
information as expected except for "as" which dumped core.

Using the cygwin supplied gdb, it looks like the problem is 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 I understand
how this type of addressing on the x86 is done.


Has anyone seen this type of failure before?  Any suggested paths to debug this?

Thanks,
John Faith
mailto:jfaith@lineo.com




------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]