Bug#489019: Vortex86SX chip

[Islam Samir Badrel-Dein]

I am not able to reproduce this bug anymore!! I am compiling using Lenny 
gcc and glibc and no errors are encountered. I think this bug should be 
marked invalid, I'll continue compiling programs from Lenny until this 
bug shows up again, or as I hope, everything goes smoothly.


Thanks much for your time. Your support is really appreciated.

Best Regards,
Islam



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489019: glibc 2.7 build configuration not suitable for Vortex86SX chip (486 compatible)

[Islam Samir Badrel-Dein]

Aurelien Jarno wrote:

Islam Samir Badrel-Dein a écrit :
  

Aurelien Jarno wrote:


Could you please use gdb to find the offending instruction?

  
  

Unfortunately I don't have gdb on my target as it is all compiled from



Then please generate a core on the machine, and examine it on another
machine where you can install gdb.

  
Sorry, but I really don't understand what this means or how to do it? I 
am still newbie to embedded Linux :) Anyway, I'll try soon to install 
Debian Sarge or even puppylinux on this machine to have access to gdb 
and all other stuff. I'll try it then!


-Islam

Bug#489019: Vortex86SX chip

[Islam Samir Badrel-Dein]

Petr Salinger wrote:


Once again, what is the kernel of your TARGET system, i.e. on 
Vortex86SX chip. Is it really 2.6.25.5 with FPU emulation enabled ?
Yes, the kernel for the TARGET system is 2.6.25.5 from Kernel.org with 
no patches and with FPU emulation enabled.


Or 2.6.25.5 is version available on the system, where you are building 
packages ?

How did you installed debian/libraries to the TARGET system.
By dpkg -i, or by copying some files ?
I prepared the whole target system by copying files, using my custom 
built busybox binary.



-Islam



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489019: Vortex86SX chip

[Islam Samir Badrel-Dein]

Petr Salinger wrote:



You did not answer my very important question:


What is the kernel of your target system


Sorry, I really forgot to answer it! My kernel is 2.6.25.5, so lenny/sid 
should be no problem. The point is: my installation is on a VirtualBox 
virtual machine. I installed Debian Etch on it and then upgraded the gcc 
and the libc to lenny (mainting a mixed stable/testing system by now). I 
have another VM with pure Debian Etch. Also, a third VM with pure Debian 
Sarge (oldstable). I am using those machines as my build systems instead 
of chroot. They are ALL 32-bit installations. The situation is:


Lenny --> The bug exists for both static and shared binaries

Etch --> Static binaries works perfect but shared binaries still have 
the bug


Sarge --> Both static and shared binaries are working perfect

My conclusion was that there is a problem with the pre-compiled binaries 
of the C shared library and/or the dynamic link loader ld-linux.so.2 on 
Debian Etch, since shared binaries are not working correctly. Please 
note that I copy the needed shared libraries AS IS to the /lib/ 
directory of my target to test the shared binaries.


And, of the three I have, I am filing this bug against the Lenny build 
system. That's why my bug report contains the versions of Lenny.


From the Sarge machine, I am currently doing all my builds and they are 
working great! I wonder why the Lenny system produces that bug? They are 
both 32-bit installations anyway!


Thanks for your time and support,

-Islam



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489019: Vortex86SX chip

[Islam Samir Badrel-Dein]

Petr Salinger wrote:

Hi,

it looks like you use 64 bit environment.
Is it true ?

The "gcc -m32 -march=486" will produce i486 compliant code, BUT
the startup files and whole glibc is compiled with -march=686,
so the resulting binary wouldn't be.

You have to use 32 bit chroot, see also man debootstrap.

What is the kernel of your target system,
does FPU emulation work correctly ?
How output of "cat /proc/cpuinfo" looks ?

Petr



Hello again Petr,

This is the output of "cat /proc/cpuinfo"
processor: 0
vendor_id: unknown
cpu family: 4
model: 0
model name: 486
stepping: unknown
fdiv_bug: yes
hlt_bug: no
f00f_bug: no
coma_bug: no
fpu: no
fpu_exception: no
cpuid level: -1
wp: yes
flags:
bogomips: 99.32
clflush size: 32

Also, I suppose floating point emulation is working correctly, though 
slowly, as most Qt demos are working correctly, with demos that requires 
floating point. BTW, this is the chip homepage:

http://www.dmp.com.tw/tech/Vortex86SX/

Thanks for your time
-Islam



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489019: Vortex86SX chip

[Islam Samir Badrel-Dein]

Petr Salinger wrote:

Hi,

it looks like you use 64 bit environment.
Is it true ?

The "gcc -m32 -march=486" will produce i486 compliant code, BUT
the startup files and whole glibc is compiled with -march=686,
so the resulting binary wouldn't be.

You have to use 32 bit chroot, see also man debootstrap.

What is the kernel of your target system,
does FPU emulation work correctly ?
How output of "cat /proc/cpuinfo" looks ?

Petr


Hello Petr,

That what I realized early enough after I encountered many failures and 
thats why I started to try older and older versions of Debian on a VM. 
The only version that worked was Debian oldstable (Sarge). It seems the 
glibc was compiled for 486 then. I am filing this bug more-of a (wish) 
than a (bug). There should be someway for developers to compile code 
that would work correctly on any i386 target
without having to chroot in another environment. This is the purpose of 
the -m32 and the multilib anyway!!


Thanks,
Islam



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489019: glibc 2.7 build configuration not suitable for Vortex86SX chip (486 compatible)

[Islam Samir Badrel-Dein]

Aurelien Jarno wrote:


Could you please use gdb to find the offending instruction?

  


Unfortunately I don't have gdb on my target as it is all compiled from 
scratch. Anyway I think the real problem is the build configurations. It 
seems that the glibc is NOT compiled for generic i386, rather it seems 
to be compiled for 686, this is why even static linking fails. Please 
note that my target is a STRICT 486 processor.


-Islam



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#489019: glibc 2.7 build configuration not suitable for Vortex86SX chip (486 compatible)

[Islam Samir Badrel-Dein]

Package:  libc6
Version: 2.7-10

Compiling any program, even hello world, against this library produces 
binaries not working on any Vortex86SX-based system. The program does 
not execute and produces "Illegal Instruction" error message. This is 
always the case even when compiling as static binary with the 
-march=i486 flag. Compiling the same program using libc6 version 2.3.6 
(etch) resulted in a working *static* executable, though shared 
libraries executables still produce the same bug. The only configuration 
that worked for me was using libc6 version 2.3.2 (sarge).


The details of the whole process are on this forum 
 
(http://ubuntuforums.org/showthread.php?t=841783). I posted it there 
first as I thought it is a 64 bit problem while running Ubuntu Hardy 8.04.



I am using Debian GNU/Linux 4.0 with mixed stable/testing repos.

$gcc --version
gcc (Debian 4.3.1-2) 4.3.1

$/lib/libc.so.6
GNU C Library stable release version 2.7, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.2.3 (Debian 4.2.3-3).
Compiled on a Linux >>2.6.24.4<< system on 2008-03-28.
Available extensions:
   crypt add-on version 2.1 by Michael Glad and others
   GNU Libidn by Simon Josefsson
   Native POSIX Threads Library by Ulrich Drepper et al
   BIND-8.2.3-T5B
For bug reporting instructions, please see:
.


$uname -a
Linux debian 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686 
GNU/Linux.