Hi jan,
I was able to reproduce the issue with sample program.
Program was:
1 #include <sys/vfs.h>
2 #include <sys/types.h>
3 #include <sys/statfs.h>
4 #include <stdio.h>
5
6 int main()
7 {
8 int ret;
9 ret = fstatfs(-1, NULL);
10 printf("return fstatfs %d\n ",ret);
11 return 0;
12 }
13
Compiled using the following command
gcc fstatpgm1.c -D_FILE_OFFSET_BITS=64 -march=octeon2 -mabi=64 -msoft-float
-Wall -Wextra -fno-strict-aliasing -O2 -o out1 -mabi=64 -msoft-float
-L/usr/lib64
those extra flags and libraries are required for the test system. A warning was
given
fstatpgm1.c: In function 'main':
fstatpgm1.c:9: warning: null argument where non-null required (argument 2)
2. file out1
out1: ELF 64-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), for
GNU/Linux 2.6.9, statically linked, not stripped
output uname -a
SMP PREEMPT mips64 GNU/Linux
3. I ran the binary using strace. It is not showing fstafs
$ strace ./out1
execve("./out1", ["./out1"], [/* 15 vars */]) = 0
brk(0) = 0x120011000
uname({sys="Linux", node="CPU1", ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x556219c000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib64/tls/octeon2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or
directory)
stat("/lib64/tls/octeon2", 0xffffc3e5e0) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/lib64/tls", 0xffffc3e5e0) = -1 ENOENT (No such file or directory)
open("/lib64/octeon2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or
directory)
stat("/lib64/octeon2", 0xffffc3e5e0) = -1 ENOENT (No such file or directory)
open("/lib64/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\0\0\0\3b\250"...,
832) = 832
lseek(3, 60728, SEEK_SET) = 60728
read(3, "\0\0\0\4\0\0\0\20\0\0\0\1GNU\0\0\0\0\0\0\0\0\2\0\0\0\6\0\0\0\t", 32) =
32
fstat(3, {st_mode=S_IFREG|0755, st_size=1693440, ...}) = 0
mmap(NULL, 1679632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x55621ae000
mprotect(0x5562323000, 61440, PROT_NONE) = 0
mmap(0x5562332000, 73728, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x174000) = 0x5562332000
mmap(0x5562344000, 16656, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x5562344000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x556219d000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x556219e000
set_thread_area(0x55621a4b90) = 0
mprotect(0x5562332000, 57344, PROT_READ) = 0
mprotect(0x55621ab000, 4096, PROT_READ) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x5562349000
write(1, "return fstatfs 1646910064\n", 26return fstatfs 1646910064
) = 26
write(1, " ", 1 ) = 1
exit_group(0) = ?
4. The issue was reproducible. So I build it static
gcc -g fstatpgm1.c -D_FILE_OFFSET_BITS=64 -march=octeon2 -mabi=64 -msoft-float
-Wall -Wextra -fno-strict-aliasing -O2 -o out1 -mabi=64 -msoft-float
-L/usr/lib64 -static
objdump follows.
main():
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:7
120003b50: 67bdfff0 daddiu sp,sp,-16
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:9
120003b54: 2404ffff li a0,-1
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:7
120003b58: ffbc0000 sd gp,0(sp)
120003b5c: 3c1c000b lui gp,0xb
120003b60: 0399e02d daddu gp,gp,t9
120003b64: ffbf0008 sd ra,8(sp)
120003b68: 679c0320 daddiu gp,gp,800
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:9
120003b6c: df998708 ld t9,-30968(gp)
120003b70: 0320f809 jalr t9
120003b74: 0000282d move a1,zero
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:10
120003b78: df848048 ld a0,-32696(gp)
120003b7c: df999530 ld t9,-27344(gp)
120003b80: 0040282d move a1,v0
120003b84: 0320f809 jalr t9
120003b88: 6484ab78 daddiu a0,a0,-21640
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:12
120003b8c: dfbf0008 ld ra,8(sp)
120003b90: dfbc0000 ld gp,0(sp)
120003b94: 0000102d move v0,zero
120003b98: 03e00008 jr ra
120003b9c: 67bd0010 daddiu sp,sp,16
__libc_start_main():
120003ba0: 67bdfed0 daddiu sp,sp,-304
5. I am using
libc.so.6 => /lib64/libc.so.6
/lib64/ld.so.1
/lib64/libc.so.6 -> libc-2.11.1.so
gcc version 4.4.1
I don’t understand objdump output much. Sorry to tell that. How to analyze it?
Regards
Ajoy
-----Original Message-----
From: Jan Stancek [mailto:jstan...@redhat.com]
Sent: Monday, June 23, 2014 8:18 PM
To: Ajoymon Joseph
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] fstatfs02 issue on mips64
----- Original Message -----
> From: "Ajoymon Joseph" <ajoy.jos...@lnttechservices.com>
> To: "Jan Stancek" <jstan...@redhat.com>
> Cc: ltp-list@lists.sourceforge.net
> Sent: Monday, 23 June, 2014 3:26:55 PM
> Subject: RE: [LTP] fstatfs02 issue on mips64
>
> I am not seeing fstatfs call itself when comparing the system call. I hope
> this is the reason?
> Also fstatfs02 was working fine. Only fstatfs02_64 was having the issue.
> I saw in ../utils/newer_64.mk makefile. It will be good if you tell little
> more about the 64 here.
It compiles the testcase with -D_FILE_OFFSET_BITS=64, which should have effect
only on 32 bit systems. [1]
1. Can you verify, that you can reproduce this issue with following program,
if you add compiler flag "-D_FILE_OFFSET_BITS=64"?
For example: gcc fstatfs.c -D_FILE_OFFSET_BITS=64
$ cat fstatfs.c
#include <sys/vfs.h>
#include <sys/types.h>
#include <sys/statfs.h>
#include <stdio.h>
int main()
{
fstatfs(-1, NULL);
return 0;
}
2. You mentioned mips64, is both kernel and userspace 64bit?
Once you compile for your test system, can you run "file" on the binary?
$ file ./a.out
3. If you run the binary via strace on test system, does it show calls to
fstatfs()?
4. If you can reproduce it with simple program above, can you compile it
statically,
for example: $ gcc fstatfs.c -D_FILE_OFFSET_BITS=64 -static
and have a look at disassembly of statfs function?
$ objdump -d ./a.out | less
You will need to use objdump from your toolchain.
5. What libc/uclibc library are you using on test system?
Regards,
Jan
[1]
http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#Feature-Test-Macros
>
> I am working on 2.6.32.46 kernel.
>
> Regards
> Ajoy
>
>
>
>
>
> -----Original Message-----
> From: Jan Stancek [mailto:jstan...@redhat.com]
> Sent: Monday, June 23, 2014 5:13 PM
> To: Ajoymon Joseph
> Cc: ltp-list@lists.sourceforge.net
> Subject: Re: [LTP] fstatfs02 issue on mips64
>
>
>
> ----- Original Message -----
> > From: "Ajoymon Joseph" <ajoy.jos...@lnttechservices.com>
> > To: ltp-list@lists.sourceforge.net
> > Sent: Friday, 20 June, 2014 3:41:06 PM
> > Subject: [LTP] fstatfs02 issue on mips64
> >
> >
> >
> > Hi,
> >
> > I am testing mips64 with LTP. The problem is with fstatfs02.c file. The
> > test
> > case was failing in my particular arch. For debugging purpose I write the
> > same code and executed.
> >
> > ret = fstatfs( -1,&buf );
> >
> > printf("Retrun value =%d, errornumber %d EBADF is %d %s FD %d pointer %p
> > \n",ret,errno, EBADF,strerror(errno),-1,&buf);
> >
> > it was giving a output like
> >
> > Retrun value =- 1 , errornumber 9 EBADF is 9 Bad file descriptor FD -1
> > pointer 0x120011130
> >
> > But when I executed LTP testcase with some debug print added
> >
> > TEST(fstatfs(TC[i].fd, (TC[i]).sbuf));
> >
> > if (TEST_RETURN != -1) {
> >
> > tst_resm(TFAIL, "call succeeded unexpectedly return %d %s FD %d, pointer
> > sbuf
> > %p ",TEST_RETURN,strerror(errno),TC[i].fd, TC[i].sbuf);
> >
> > I got a print like this
> >
> > fstatfs02 1 TFAIL : call succeeded unexpectedly return 1690729072 Success
> > FD
> > -1, pointer sbuf 0x12001ba30
> >
> > I feel like both are doing the same job… But when I am running it in LTP
> > environment I am getting a return as 1690729072. I was not able to find any
> > problem in TEST macro. Can anyone please help me out in debugging this.
>
> What kernel/LTP release are you using?
>
> You can try running good and bad case via strace. If parameters will be
> correct and you still get strange numbers in strace output, it's likely a
> kernel bug.
>
> Regards,
> Jan
> L&T Technology Services Ltd
>
> www.LntTechservices.com<http://www.lnttechservices.com/>
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do not
> use or disseminate the information, notify the sender and delete it from
> your system.
>
L&T Technology Services Ltd
www.LntTechservices.com<http://www.lnttechservices.com/>
This Email may contain confidential or privileged information for the intended
recipient (s). If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
