Cross compiled cross assembler dumps core
Mon Nov 27 09:21:00 GMT 2000
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-"
On Linux, binutils was configured with:
$ ../binutils-2.10/configure --host=i586-cygwin32 --target=i586-pc-linux-gnu \
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,
The offending assembly instruction seems to be:
, 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?
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to firstname.lastname@example.org
More information about the crossgcc