----- Original Message -----
> From: "Ajoymon Joseph" <ajoy.jos...@lnttechservices.com>
> To: "Jan Stancek" <jstan...@redhat.com>
> Cc: ltp-list@lists.sourceforge.net
> Sent: Tuesday, 24 June, 2014 8:35:45 AM
> Subject: RE: [LTP] fstatfs02 issue on mips64
>
> 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
According to [1], e_flags seems to be EF_MIPS_ARCH_32R2, meaning:
"This file will run on a machine with the architecture describe for Mips32
Revision 2"
Which looks a bit suspicious, given that this is supposed to be 64bit.
I'm assuming if you compile following:
printf("%d\n", sizeof(struct statfs));
with and without "-D_FILE_OFFSET_BITS=64" it is going to give you different
numbers.
Just a wild guess, can you try to compile/run reproducer with "-march=mips64r2"
instead of "-march=octeon2" ?
[1] https://dmz-portal.mips.com/wiki/MIPS_ELF_header_definitions
>
> output uname -a
> SMP PREEMPT mips64 GNU/Linux
>
> 3. I ran the binary using strace. It is not showing fstafs
>
>
> 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.
Was that whole objdump output? It didn't show fstatfs() function,
just main() and __libc_start_main().
>
> 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'm assuming this is from test system.
Anyway, we confirmed, that it's not a bug in LTP. You were able to reproduce it
with sample program above, which is not including/linking LTP. I suggest you
also reach out to your BSP vendor and ask him about this behaviour.
Regards,
Jan
>
> 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
