#include <re.h> required for Opteron but not Pentium.

[Jim Freeze]

Hi

While porting to an opteron 64bit computer, we noticed one
of our .so file was aborting. The problem was fixed by
adding a simple #include <re.h> to the .c file.

My question is, why is it required to include this file for opteron,
but not for the 32bit x86 machines. Without the include statement, I get
the error below on the 64 bit machine, but not on 32bit x86
or 64bit Solaris.

uname -a
Linux op2 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:32:58 EDT 2003 x86_64
x86_64 x86_64 GNU/Linux

make
gcc -fPIC -O2 -g -pipe -Wall -fPIC -I.
-I/usr/lib64/ruby/1.8/x86_64-linux-gnu
-I/usr/lib64/ruby/1.8/x86_64-linux-gnu -I. -c netlistparser.c
netlistparser.c: In function `Init_netlistparser':
netlistparser.c:113: warning: implicit declaration of function
`rb_reg_regcomp'
gcc -shared -L"/usr/lib64" -o netlistparser.so netlistparser.o -lruby
-ldl -lcrypt -lm -lc

 

[Tim Hunter]

Hi

While porting to an opteron 64bit computer, we noticed one
of our .so file was aborting. The problem was fixed by
adding a simple #include <re.h> to the .c file.

My question is, why is it required to include this file for opteron,
but not for the 32bit x86 machines. Without the include statement, I get
the error below on the 64 bit machine, but not on 32bit x86
or 64bit Solaris.

uname -a
Linux op2 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:32:58 EDT 2003 x86_64
x86_64 x86_64 GNU/Linux

make
gcc -fPIC -O2 -g -pipe -Wall -fPIC -I.
-I/usr/lib64/ruby/1.8/x86_64-linux-gnu
-I/usr/lib64/ruby/1.8/x86_64-linux-gnu -I. -c netlistparser.c
netlistparser.c: In function `Init_netlistparser':
netlistparser.c:113: warning: implicit declaration of function
`rb_reg_regcomp'
gcc -shared -L"/usr/lib64" -o netlistparser.so netlistparser.o -lruby
-ldl -lcrypt -lm -lc

Almost certainly the actual function definition doesn't match with the
defaults used by the compiler in the absence of a prototype. I don't
have access to the ruby source here but my guess is that
rb_reg_regcomp actually uses/returns a 64-bit value but the compiler
assumed a 32-bit value. When you execute the .so, rb_reg_regcomp puts
a 64-bit value on the stack but the caller only takes a 32-bit value
off. Boom. Adding the include file makes the prototype available to
the compiler.

 

[Jim Freeze]

Almost certainly the actual function definition doesn't match with the
defaults used by the compiler in the absence of a prototype. I don't
have access to the ruby source here but my guess is that
rb_reg_regcomp actually uses/returns a 64-bit value but the compiler
assumed a 32-bit value. When you execute the .so, rb_reg_regcomp puts
a 64-bit value on the stack but the caller only takes a 32-bit value
off. Boom. Adding the include file makes the prototype available to
the compiler.

Should this be fixed in ruby.h?

 

[Tim Hunter]

Should this be fixed in ruby.h?

Offhand, it seems to me that nothing is broken (except for the C language
itself, of course . Now that I have access to the Ruby sources, I see
that VALUE is a typedef for a long. I guess longs are 64 bits on the
Opteron. Without a prototype or other declaration in scope, the compiler
assumes that rb_reg_regcomp returns an int. Including the right header
file is the fix.

Of course the final decision is nobu's.

 

[Nobuyoshi Nakada]

Hi,

At Thu, 10 Jun 2004 08:43:39 +0900,
Tim Hunter wrote in [ruby-talk:103007]:

Offhand, it seems to me that nothing is broken (except for the C language
itself, of course . Now that I have access to the Ruby sources, I see
that VALUE is a typedef for a long. I guess longs are 64 bits on the
Opteron. Without a prototype or other declaration in scope, the compiler
assumes that rb_reg_regcomp returns an int. Including the right header
file is the fix.

IMHO, It would be the only reasonable solution. If you use
regexp engine stuffs you should include re.h, I guess, since
ruby.h doesn't cover them.

Of course the final decision is nobu's.

Not me.

 

[Nobuyoshi Nakada]

Hi,

At Thu, 10 Jun 2004 08:43:39 +0900,
Tim Hunter wrote in [ruby-talk:103007]:

Offhand, it seems to me that nothing is broken (except for the C language
itself, of course . Now that I have access to the Ruby sources, I see
that VALUE is a typedef for a long. I guess longs are 64 bits on the
Opteron. Without a prototype or other declaration in scope, the compiler
assumes that rb_reg_regcomp returns an int. Including the right header
file is the fix.

IMHO, It would be the only reasonable solution. If you use
regexp engine stuffs you should include re.h, I guess, since
ruby.h doesn't cover them.

Of course the final decision is nobu's.

Not me.

 

[Jim Freeze]

Hi,

At Thu, 10 Jun 2004 08:43:39 +0900,
Tim Hunter wrote in [ruby-talk:103007]:

Offhand, it seems to me that nothing is broken (except for the C language
itself, of course . Now that I have access to the Ruby sources, I see
that VALUE is a typedef for a long. I guess longs are 64 bits on the
Opteron. Without a prototype or other declaration in scope, the compiler
assumes that rb_reg_regcomp returns an int. Including the right header
file is the fix.

IMHO, It would be the only reasonable solution. If you use
regexp engine stuffs you should include re.h, I guess, since
ruby.h doesn't cover them.

I understand the problem now.
Should ruby.h include re.h?

I'm trying to find a solution that works on both 32bit and 64bit
machines without code changes. And it would be best if I didn't
have to have it fail on a 64bit machine to find out.

Also, there is no problem with Solaris. Do the C compilers on sun
assume 32bit longs on the 64bit machines...maybe I should go look.

 

[nobu.nokada]

Hi,

At Thu, 10 Jun 2004 13:47:54 +0900,
Jim Freeze wrote in [ruby-talk:103037]:

I understand the problem now.
Should ruby.h include re.h?

I don't think so. All sources using ruby.h don't need regexp
stuffs.

I'm trying to find a solution that works on both 32bit and 64bit
machines without code changes. And it would be best if I didn't
have to have it fail on a 64bit machine to find out.

Why without changes? It isn't your own code?

 

[Jim Freeze]

Hi,

At Thu, 10 Jun 2004 13:47:54 +0900,
Jim Freeze wrote in [ruby-talk:103037]:

I understand the problem now.
Should ruby.h include re.h?

I don't think so. All sources using ruby.h don't need regexp
stuffs.

I'm trying to find a solution that works on both 32bit and 64bit
machines without code changes. And it would be best if I didn't
have to have it fail on a 64bit machine to find out.

Why without changes? It isn't your own code?

No, it's my code. I just find it a little disconcerting that the missing
include did not even generate a warning for the 32bit compile, but
it is required for the 64bit compile.

 

[Tim Hunter]

I'm trying to find a solution that works on both 32bit and 64bit
machines without code changes. And it would be best if I didn't
have to have it fail on a 64bit machine to find out.

Include "re.h" in your source file. It's always the right thing to do.

Also, there is no problem with Solaris. Do the C compilers on sun
assume 32bit longs on the 64bit machines...maybe I should go look.

Some 64-bit machines use 64-bit pointers but longs are 32 bits. Others
make both pointers and longs 64 bits. I don't know which camp Solaris
is in. In all cases including re.h solves the problem.

 

[Jim Freeze]

Quoteing (e-mail address removed), on Thu, Jun 10, 2004 at 03:21:59PM +0900:

What compiler are you using? Are you sure you have the warning levels
cranked high? Default build options on many compilers won't tell you
about this kind of stuff.

gcc

The warnings are whatever is generated by mkmf/create_makefile by default.

./a.out

sizeof(char) 1 bytes 8 bits
sizeof(short) 2 bytes 16 bits
sizeof(int) 4 bytes 32 bits
sizeof(void *) 4 bytes 32 bits
sizeof(float) 4 bytes 32 bits
sizeof(double) 8 bytes 64 bits
sizeof(long) 4 bytes 32 bits
sizeof(long long)8 bytes 64 bits

uname -a

SunOS juno 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-5_10

Apparently, our 64bit suns are using a 32bit compiler
and hence the 32bit pointers.

./a.out

sizeof(char) 1 bytes 8 bits
sizeof(short) 2 bytes 16 bits
sizeof(int) 4 bytes 32 bits
sizeof(void *) 8 bytes 64 bits
sizeof(float) 4 bytes 32 bits
sizeof(double) 8 bytes 64 bits
sizeof(long) 8 bytes 64 bits
sizeof(long long)8 bytes 64 bits

uname -a

Linux op2 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:32:58 EDT 2003 x86_64
x86_64 x86_64 GNU/Linux


--
Jim Freeze
A [golf] ball sliced or hooked into the rough shall be lifted and
placed in the fairway at a point equal to the distance it carried or
rolled into the rough. Such veering right or left frequently results
from friction between the face of the club and the cover of the ball
and the player should not be penalized for the erratic behavior of the
ball resulting from such uncontrollable physical
phenomena.
-- Donald A. Metz