Get if embedded system supports large file

Hi !

You could get the file system type of the OS then with the file system type you could know the limitation.

Best Regards

~ # cat /proc/version
Linux version 2.4.34-pre2 (root@linux) (gcc version 3.4.6 (OpenWrt-2.0)) #170 Fr
i Sep 15 20:10:21 CEST 2006

Could I know the file system type?
Any help would be appreciated.

Hi !

Do :

cat /etc/fstab

You will see your system file like : ext3, or ext2, reiserfs



Best Regards

If the file system type of OS is ext3, how could I know the limitiation?
Where could I get the infomration?

Any help would be appreciated.

Hi !

I find this :

http://www.suse.de/~aj/linux_lfs.html

But that not only depend of the file system it also depend of the kernel that you using and how you compile your application.

Best Regards

The question is not whether your file systems supports large files or your kernel version.

Your problem is whether you have the library functions which support 64-bit file offsets, like fstat64.  This depends on which C library you have installed and how the library was built,  The C library is usually found in /usr/lib/libc.a or /lib/libc.a.  There are also .so versions.  

You can check if your library contains 64-bit file functions by executing
  nm libc.a | grep 64 | grep T
If you see listings like "00000000 T fstat64" or similar names then the library has this support.  

I can't find the libc.a.

find / -name  '*libc*'
/jffs/opt/lib/ld-uClibc-0.9.28.so
/jffs/opt/lib/libcrypt-0.9.28.so
/jffs/opt/lib/libc.so
/jffs/opt/lib/ld-uClibc.so.0
/jffs/opt/lib/libuClibc-0.9.28.so
/jffs/opt/lib/libcrypt.so.0
/jffs/opt/lib/libcrypt.so
/jffs/opt/lib/libc.so.0
/jffs/jffs/usr/lib/ipkg/info/uclibc-opt.list
/lib/ld-uClibc.so.0
/lib/libc.so.0
/lib/libcrypt.so.0

How to check if shared library contains 640bit file functions?
Any help would be appreciated.

You can also look for the functions in libc.so. This is the shared version of libc.

/jffs/opt/lib # ls -al libc*
lrwxrwxrwx    1 root     root            9 Oct 23 08:54 libc.so -> libc.so.0
lrwxrwxrwx    1 root     root           19 Oct 23 08:55 libc.so.0 -> libuClibc-0
.9.28.so
-rw-r--r--    1 root     root        11552 Oct 23 08:52 libcrypt-0.9.28.so
lrwxrwxrwx    1 root     root           13 Oct 23 08:55 libcrypt.so -> libcrypt.
so.0
lrwxrwxrwx    1 root     root           18 Oct 23 08:55 libcrypt.so.0 -> libcryp
t-0.9.28.so

libc.so->libc.so.0->libuClibc-0.9.28.so

# file ld-uClibc-0.9.28.so
ld-uClibc-0.9.28.so: ELF 32-bit LSB shared object, MIPS, version 1 (SYSV), stripped
# nm ld-uClibc-0.9.28.so
nm: ld-uClibc-0.9.28.so: no symbols

The libcuClibc-0.9.28.so is already stripped. How could I check if the library contains those function?
Any help would be appreciated.

You can do the same kind of test that autoconf uses:  Create a small program which calls a 64-bit function and check if it compiles.  If it succeeds, then you have 64-bit support. I've attached a small test program.  Run "gcc testfstat64.c" and if it compiles, you have 64-bit support.

testfstat64.c:
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
 
int main(void)
{
  struct stat buf;
  fstat64 ("/path/to/nowhere", &buf);
  return 0;
}

Select allOpen in new window

I run "mipsel-linuc-gcc -o testfstat64 testfstat64" and it compiles. But I download this "testfstat64" binary file to target platform, and run it.
It shows me:

~ # ./testfstat64./testfstat64: can't resolve symbol 'fstat64'


Althought the testfstat64 is compiled without any errors on Host Platform, I can sure that I have 64-bit suuport on Target Platform.

Corret:

Althought the testfstat64 is compiled without any errors on Host Platform, I can NOT sure that I have 64-bit suuport on Target Platform.

Sorry, it needs to be compiled and executed to indicate that you have the support.  The reference to fstat64 will only be checked when the program is loaded.  

Before, you ran nm on ld-uClibc-0.9.28.so.  This is not the C library, it is the loader.  Run nm on libuClibc-0.9.28.so which is what libc.so points to.

Yes. I run nm on libuClibc-0.9.28.so.

# file ld-uClibc-0.9.28.so
ld-uClibc-0.9.28.so: ELF 32-bit LSB shared object, MIPS, version 1 (SYSV), stripped
# nm ld-uClibc-0.9.28.so
nm: ld-uClibc-0.9.28.so: no symbols

Why do you believe the ld-uClibc-0.9.28.so  is the same as libuClibc-0.9.28.so?

Sorry. I mistook libuClibc-0.9.28.so for ld-uClibc-0.9.28.so.

# file libuClibc-0.9.28.solibuClibc-0.9.28.so: ELF 32-bit LSB shared object, MIPS, version 1 (SYSV), stripped# nm libuClibc-0.9.28.sonm: libuClibc-0.9.28.so: no symbols
The result is the same.

Which version of nm are you running?  You may need to run the mips version, otherwise you will have endianity issues.  

I also run the mips version, the result is the same.

# mipsel-linuc-nm libuClibc-0.9.28.so
mipsel-linuc-nm: libuClibc-0.9.28.so: no symbols

This is odd.  Shared libraries have to have symbols, otherwise there is no way to link to functions in the library.

Please run "ldd ./testfstat64" on your target.

If the library is stripped, can I get the symbols?

In my target platform, there is no "ldd" command.

Stripping a library removes debugging information.  The symbols are still present.  

Look for other commands on your target.  objdump and readelf should both display symbols.

$ mipsel-linux-objdump -D libuClibc-0.9.28.so | grep fstat64
00052090 <fstat64>:
   520c8:       10e00007        beqz    a3,520e8 <fstat64+0x58>
   520e0:       1000000a        b       5210c <fstat64+0x7c>
   520f4:       14400005        bnez    v0,5210c <fstat64+0x7c>

$ mipsel-linux-readelf -a libuClibc-0.9.28.so | grep fstat64
  1300: 00052090   148 FUNC    GLOBAL DEFAULT    7 fstat64


I could find the 'fstat64' symbol. What 's the next step to confirm if libuClibc-0.9.28.so supports fstat64 function?

I study "Object Files in Executable and Linking Format (ELF):http://docs.sun.com/app/docs/doc/802-1948/6i5uqa9po?l=zh_TW&a=view".

$ mipsel-linux-readelf -a libuClibc-0.9.28.so | grep fstat64
  1300: 00052090   148 FUNC    GLOBAL DEFAULT    7 fstat64

Type: FUNC
Symbol is associated with a function or other executable code. When another object file references a function from a shared object, the link editor automatically creates a procedure linkage table entry for the referenced symbol.

Binding:GLOBAL
Symbol is either defined externally or defined in the object file and accessible in other files.

fstat64 is associated with a function which is defined externally or defined in the object object and accessible in other files.

Which library should I check if the fstat64 inside? Any help would be appreciated.

# mipsel-linux-objdump -D libuClibc-0.9.28.so > result# vim result

00052090 <fstat64>:   52090:       3c1c0006        lui     gp,0x6   52094:       279c4710        addiu   gp,gp,18192   52098:       0399e021        addu    gp,gp,t9   5209c:       27bdff70        addiu   sp,sp,-144   520a0:       afbf0088        sw      ra,136(sp)   520a4:       afb10084        sw      s1,132(sp)   520a8:       afb00080        sw      s0,128(sp)   520ac:       afbc0010        sw      gp,16(sp)   520b0:       27a60018        addiu   a2,sp,24   520b4:       00a08821        move    s1,a1   520b8:       00c02821        move    a1,a2   520bc:       24021077        li      v0,4215   520c0:       0000000c        syscall   520c4:       8f9981f8        lw      t9,-32264(gp)   520c8:       10e00007        beqz    a3,520e8 <fstat64+0x58>   520cc:       00408021        move    s0,v0   520d0:       0320f809        jalr    t9   520d4:       00000000        nop   520d8:       8fbc0010        lw      gp,16(sp)   520dc:       2403ffff        li      v1,-1   520e0:       1000000a        b       5210c <fstat64+0x7c>   520e4:       ac500000        sw      s0,0(v0)   520e8:       8f998558        lw      t9,-31400(gp)   520ec:       00401821        move    v1,v0   520f0:       00c02021        move    a0,a2   520f4:       14400005        bnez    v0,5210c <fstat64+0x7c>   520f8:       02202821        move    a1,s1   520fc:       0320f809        jalr    t9   52100:       00000000        nop   52104:       8fbc0010        lw      gp,16(sp)   52108:       00001821        move    v1,zero   5210c:       8fbf0088        lw      ra,136(sp)   52110:       8fb10084        lw      s1,132(sp)   52114:       8fb00080        lw      s0,128(sp)   52118:       00601021        move    v0,v1   5211c:       03e00008        jr      ra   52120:       27bd0090        addiu   sp,sp,144
        ...

The libuClibc-0.9.28.so supports fstat64, right?

# mipsel-linux-objdump libuClibc-0.9.28.so -T | grep fstat64
00052090 g    DF .text  00000094 fstat64

# mipsel-linux-objdump -T testfstat64
testfstat64:     file format elf32-tradlittlemips

DYNAMIC SYMBOL TABLE:
10000020 g    D  .data  00000000  Base        _fdata
10008050 g    d  *ABS*  00000000              _gp_disp
00000001 g    d  *ABS*  00000000  Base        _DYNAMIC_LINKING
00400120 g    DO *ABS*  00000000  Base        _DYNAMIC
10008050 g    D  *ABS*  00000000  Base        _gp
004005e0 g    D  .text  00000000  Base        _ftext
10000050 g    DO .rld_map       00000000  Base        __RLD_MAP
1000009c g    D  *ABS*  00000000  Base        __bss_start
1000009c g    D  *ABS*  00000000  Base        _edata
10000060 g    DO *ABS*  00000000  Base        _GLOBAL_OFFSET_TABLE_
100000c0 g    D  *ABS*  00000000  Base        _end
1000009c g    D  *ABS*  00000000  Base        _fbss
00000000  w   D  *UND*  00000000              _Jv_RegisterClasses
00000000  w   DF *UND*  0000001c  GCC_3.0     __register_frame_info
00400870 g    DF .fini  0000001c  Base        _fini
00400770 g    DF .text  00000064  Base        main
00400850      DF *UND*  00000244              __uClibc_main
00000000  w   DF *UND*  0000001c  GCC_3.0     __deregister_frame_info
0040054c g    DF .init  0000001c  Base        _init
00400840      DF *UND*  00000094              fstat64

Run "mipsel-linux-objdump -p testfstat64" to see the contents of the Dynamic Section.  It should start like this:

Dynamic Section:
  NEEDED      libc.so.6    
  INIT        0x80482b0
  FINI        0x8048508
  ...

This tells which shared library is required.  

testfstat64 -> libc.so.0 -> libuClibc-0.9.28.so

 libuClibc-0.9.28.so have fstat64 function, but "can't resolve symbol 'fstat64'".
Why?

I find the shared library the testfstat64 needed is libgcc_s.so.1 NOT libuClibc-0.9.28.so.

mipsel-linux-objdump -p testfstat64
 
testfstat64:     file format elf32-tradlittlemips
 
Program Header:
    PHDR off    0x00000034 vaddr 0x00400034 paddr 0x00400034 align 2**2
         filesz 0x000000c0 memsz 0x000000c0 flags r-x
  INTERP off    0x000000f4 vaddr 0x004000f4 paddr 0x004000f4 align 2**0
         filesz 0x00000014 memsz 0x00000014 flags r--
0x70000000 off    0x00000108 vaddr 0x00400108 paddr 0x00400108 align 2**2
         filesz 0x00000018 memsz 0x00000018 flags r--
    LOAD off    0x00000000 vaddr 0x00400000 paddr 0x00400000 align 2**12
         filesz 0x000008f4 memsz 0x000008f4 flags r-x
    LOAD off    0x00001000 vaddr 0x10000000 paddr 0x10000000 align 2**12
         filesz 0x0000009c memsz 0x000000c0 flags rw-
 DYNAMIC off    0x00000120 vaddr 0x00400120 paddr 0x00400120 align 2**2
         filesz 0x000003e0 memsz 0x000003e0 flags rwx
 
Dynamic Section:
  NEEDED      libgcc_s.so.1
  NEEDED      libc.so.0
  INIT        0x40054c
  FINI        0x400870
  HASH        0x400218
  STRTAB      0x400408
  SYMTAB      0x4002b8
  STRSZ       0xf8
  SYMENT      0x10
  0x70000016  0x10000050
  DEBUG       0x0
  PLTGOT      0x10000060
  REL         0x0
  RELSZ       0x0
  RELENT      0x8
  0x70000001  0x1
  0x70000005  0x2
  0x70000006  0x400000
  0x7000000a  0x7
  0x70000011  0x15
  0x70000012  0x1a
  0x70000013  0xd
  VERNEED     0x40052c
  VERNEEDNUM  0x1
  VERSYM      0x400500
 
Version References:
  required from libgcc_s.so.1:
    0x0b792650 0x00 02 GCC_3.0
private flags = 50001007: [abi=O32] [mips32] [not 32bitmode]

Select allOpen in new window

Sorry, I mistook.

  NEEDED      libgcc_s.so.1
  NEEDED      libc.so.0

I already find the problem. Thank you.