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] |
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] |