Bug#489019: Vortex86SX chip

2008-07-06 Thread 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: Vortex86SX chip

2008-07-05 Thread 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: Vortex86SX chip

2008-07-05 Thread 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

2008-07-05 Thread Petr Salinger
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!!


Sorry, but there are really different tasks:

1) be able to run 32 bit binaries on current 64 bit system

2) be able to cross-build binaries for another system

3) install 32-bit packages on corresponding 64-bit system.

For 1), you can assume i.e. i686 capabilities on all x86-64 systems,
i.e. CMOV, SSE, ...
Exactly this assumes supporting library in libc6-i386
and libc6-dev-i386 packages, they also contain static library and
startup files linked into any executable.

You are really cross-building to another system, only by coincidence
your 64 bit system is able to run these cross-built binaries.

You did not answer my very important question:


What is the kernel of your target system


The current i386 and amd64 libc does not support 2.4 kernel series,
the amd64 system from etch also does not support 2.4 kernel series.

So, easiest sollution for you is really to install 32-bit chroot on 
your 64 bit machine. After that, you should be able to produce correct 
binaries for i486 and above CPUs (plain i386 is not supported).


Iff target kernel is 2.4.x, you have to choose etch,
for 2.6.x kernel you should be able to use also lenny/sid.

Petr



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



Bug#489019: Vortex86SX chip

2008-07-05 Thread Aurelien Jarno
Islam Samir Badrel-Dein a écrit :
 Petr Salinger wrote:
 Hi,

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


Could you please clearly answer this question? You original bug report
only mentions packages (glibc, kernel) from a plain i386 installation.

The CPU support is not the same for i386 and amd64 distributions.


 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
 
 
 


-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net



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



Bug#489019: Vortex86SX chip

2008-07-05 Thread 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

2008-07-05 Thread Petr Salinger

What is the kernel of your target system


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 ?


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 ?

Petr



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



Bug#489019: Vortex86SX chip

2008-07-05 Thread 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

2008-07-05 Thread Petr Salinger
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.



As far as I know, there are only 3 userspace instruction added by i486
compared to i386 - CMPXCHG, XADD, BSWAP.
Are they supported by Vortex86SX chip ?

Please, compile and run code bellow on Vortex86SX chip.

Also you can try to

1) create on your Vortex86SX system sarge chroot by debootstrap,
  i.e in /sarge by standard debian tools. This way you shoul get clean,
  standard debian environment.

2) point /etc/apt/sources.list to sarge, install gdb in /sarge

3) copy created /sarge chroot to /lenny

4) point /etc/apt/sources.list to lenny and try to upgrade


Petr



int main()
{
 int eax, mem;

 __asm__ __volatile__(
   bswap %0\n\t
   cmpxchg  %0,%1\n\t
   xadd %0,%1
:=r (eax)
:m (mem), 0 (eax)
:memory);

}




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