This program
int main()
{
unsigned long high = 0x0013ABC;
unsigned long low = 0xB388B94A;
unsigned long long time1 = (((unsigned long long)high << 32L) + low);
unsigned long long time = time1 / 450;
return time == 0;
}
will return different values depending on the -mregparm compiler
option. With a value of zero or one it will compute the correct
result, but with a value of two or three the value of `time' will be
zero and the return code will be one:
$ for i in 0 1 2 3 ; do gcc34 rdtsc2.c -o rdtsc2 -mregparm=$i; ./rdtsc2 ; echo
$? ; done;
0
0
1
1
This may be because the compiler generates calls to __udivdi3
uses parameter passing in register, but linking is done with libraries
that use stack parameter passing.
Extracting __udivdi3 from glibc and including it in the source code
will solve the problem.
This problem is present in both gcc 3.3.3 and gcc 3.4 on Fedora
Core 2. I have not tried later versions of gcc.
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking
--disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
This problem surfaced when I tried using `unsigned long long' in a Linux
kernel driver. The kernel is compiled with a high value for -mregparm.
rdtsc2.i
Description: Binary data
Regards /Lars ------------------------------------------------------------------- Lars Hamrén Tel...: +46(46)189090 Svensk Datorutveckling e-post: [EMAIL PROTECTED] Vadmöllan 211 WWW...: www.sdu.se S-225 94 Lund Sweden
