writev doesn't work

[GoogleCodeExporter]

I currently port BMI(Buffered Message Interface) on SX and use the SX GCC
because it is required for compiling due to GNU C extensions in the code.

As it turned out the writev system call doesn't work.

Here is a simple test.

Native SX CC:
$ /nfs/nas/scr/ws/hwwnec4-gasnet-0/tests/sxwritev_native
hello
Wrote 6 bytes and expected 6

SX GCC:
$ /nfs/nas/scr/ws/hwwnec4-gasnet-0/tests/sxwritev       
Wrote 0 bytes and expected 6

The source file is attached.

1st thing is the buffer is not written and 2nd thing is that an error is
not shown with SX GCC.

I checked that exactly the same libc is linked. For SX GCC it has the
libgcc additionally linked in comparison to native SX CC. However the
libgcc doesn't contain a writev function.

The write syscall works fine.

Original issue reported on code.google.com by danny.st...@gmail.com on 17 Sep 2009 at 8:50

Attachments:

• sxwritev.c

[GoogleCodeExporter]

Original comment by jmoc...@gmail.com on 17 Sep 2009 at 8:55

• Added labels: Priority-High, gcc, sxlibc
• Removed labels: Priority-Medium

[GoogleCodeExporter]

If I compile with sxcc and Link with sx8-nec-superux-gcc then it works.
sxcc -sx8 -c  sxwritev.c
sx8-nec-superux-gcc -o sxwritev sxwritev.o

The other way around gives an error during linking:
sx8-nec-superux-gcc -c sxwritev.c
sxcc -o sxwritev_native sxwritev.o 
sxld fatal: incompatible long types in file /SX/usr/lib0/values-Xa.o and 
sxwritev.o

Regards,

Danny

Original comment by danny.st...@gmail.com on 17 Sep 2009 at 9:23

[GoogleCodeExporter]

hmmm ... sx gcc builds code for 64-bit size_t and 64-bit long SX libraries. 
could
this be the problem? you taking the wrong set of C libraries to link against?

Original comment by jmoc...@gmail.com on 17 Sep 2009 at 10:08

[GoogleCodeExporter]

Yes sounds good, but...

sx8-nec-superux-gcc  -c sxwritev.c
sxcc -sx8 -size_t64 -o sxwritev sxwritev.o
sxld fatal: incompatible long types in file /SX/usr/lib0/lib64/values-Xa.o and 
sxwritev.o

So doesn't if size_t is 32 or 64 bit. Strange.

More tests:
sxcc -sx8 -size_t64 -c sxwritev.c
sx8-nec-superux-gcc -o sxwritev sxwritev.o
-> writev doesn't work

sxcc -sx8 -c sxwritev.c
sx8-nec-superux-gcc -o sxwritev sxwritev.o
-> writev works

However I was just curious to see if the broken part is the compiler or the 
linker.

Original comment by danny.st...@gmail.com on 17 Sep 2009 at 10:44

[GoogleCodeExporter]

I just wondering long type is always 64bit on SX. Should not depend on size_t.

Original comment by danny.st...@gmail.com on 17 Sep 2009 at 11:03

[GoogleCodeExporter]

The same is also valid with readv syscall.

Original comment by danny.st...@gmail.com on 18 Sep 2009 at 11:20

[GoogleCodeExporter]

the problem is definitely in the fact that you are using 32-bit libraries.

namely, the 32-bit lib expects the iovec.iov_len member to be 32-bit, while 
sxgcc
compiles with _SIZE_T64 being #defined implicitly, and thus the iov_len is 
64-bit.

you can confirm it by doing this:

iov.iov_len = (strlen(buf) << 32);

and building with sxgcc.

it will work (since you moved the 6 to upper 32 bits, where the 32-bit libc 
expects
it to be). prior to this, there was a 0 in the upper 32 bits, and writev() wrote
exactly 0 bytes and reported it correctly. ;)

that said: replace your libc.a with 64 bit one. actually, replace complete 
contents
of sx8-nec-superux/lib/ with the stuff from /usr/lib0/lib64/ on a1, and rebuild 
gcc
(just in case anything produced during gcc build links against any SX libs, 
which I
think it doesn't, but it's better to be safe than sorry).

I'll make sure that the wiki lists the proper lib directory to copy from an SX
installation.

Original comment by jmoc...@gmail.com on 18 Sep 2009 at 12:42

[GoogleCodeExporter]

Original comment by jmoc...@gmail.com on 18 Sep 2009 at 12:42

• Changed state: Fixed

[GoogleCodeExporter]

Regarding libs, you need to be careful on SX. There are three modes:

1: 32 bit int, 32 bit long. 64 bit long long
2: 32 bit int, 64 bit long, 64 bit long long  (like GCC)!
3: 64 bit int, 64 bit long, 64 bit long long

(3) could be the lib64 one, and that doesn't fit with the GCC mode, either!

Regards,
Erich

Original comment by efo...@gmail.com on 18 Sep 2009 at 1:23

[GoogleCodeExporter]

grrrrr ... danny, can you suggest the library set to use with the following 
type sizes:

32-bit int, 64-bit long, 64-bit long long, 64-bit size_t

(fwiw, the lib64 set I proposed seems to work nicely; will also re-run the gcc 
and
g++ testsuites again during the weekend, just to be sure nothing gets screwed 
there)

Original comment by jmoc...@gmail.com on 18 Sep 2009 at 1:36

[GoogleCodeExporter]

int and long should not be affected by this size_t parameter. 2nd matches for 
native
SX as well.

Original comment by danny.st...@gmail.com on 18 Sep 2009 at 1:40

[GoogleCodeExporter]

Just to share the info what Holger still found out regarding the 'incompatible 
long'
error when linking a SX gcc object file with SX ld. The object file header 
misses
some flags which are set by the native SX compiler. These will be read by the 
linker
and there is actually a test for long types. The header is described in 
filehdr.h and
sys/exec.h and /etc/magic. flags2 seems to influence this long type test, but
probably together with other flags. Furthermore the long type test can be 
switched
off by the undocumented '-X' SX ld flag.

However linking with GNU ld is okay and we may not need to adapt to SX ld.

Original comment by danny.st...@gmail.com on 18 Sep 2009 at 3:43

[GoogleCodeExporter]

Jaka, thank you a lot. As you mentioned the lib64 fix works perfect!

Original comment by danny.st...@gmail.com on 18 Sep 2009 at 3:50