This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6000 CGT - 64-bit Linux file system support

Hi Champs,

does the C6000 CGT's fully support 64-bit Linux file system support like XFS (the full 2^64 possible inodes) ?

If yes, from which version onwards ...


Thanks and kind regards,

one and zero

  • Are you referring to the execution of the C6000 compiler on a hosted Linux system?  Or do you mean the execution of code built by the C6000 compiler on a C6x device that is running Linux?

    Thanks and regards,

    -George

  • Hi George,

    building works on 64-bit Linux, I know. Sorry for not being clear. What I mean is if the source files reside on an xfs file-system that uses 64 bit inodes.
    Modern filesystems are starting to use 64 bit inodes, rather than 32 bit ones.
    Will building still work when files reside in the greater 32-bit inode range?

    Kind regards,
    one and zero
  • I don't expect there will be any problems. The compiler tools do not manipulate inodes directly; that is left to the operating system. The compiler makes standard system calls to get at files on disk, so it should not need to have special handling for different filesystems.
  • Hi Archaeologist,

    my customer is reporting a problem when using CGT version 7.3.8. Please see log below:

    # mkfs.xfs -V

    mkfs.xfs version 3.1.9

    # mkfs.xfs -dfile,name=fsfile,size=4t

    # mkdir -p /mnt/t

    # mount -o loop fsfile /mnt/t

    # mkdir /mnt/t/mydir

    # echo "int main() { return 0; }" > /mnt/t/mydir/test.c

    # ls -i /mnt/t/mydir/test.c

    132 /mnt/t/mydir/test.c

    # # inode has value smaller than 32 bit == TI toolchain works

    # CGTools/CGT738/bin/cl6x /mnt/t/mydir/test.c

    # echo $?

    0

    # mkdir /mnt/t/mydir2

    # echo "int main() { return 0; }" > /mnt/t/mydir2/test.c

    # ls -i /mnt/t/mydir2/test.c

    4294967425 /mnt/t/mydir2/test.c

    # # 4294967425 - (2**32) == 129 - inode value larger than 32 bit

    # CGT738/bin/cl6x /mnt/t/mydir2/test.c

    Fatal error: could not open source file "/mnt/t/mydir2/test.c"

    1 fatal error detected in the compilation of "/mnt/t/mydir2/test.c".

    Compilation terminated.



    >> Compilation failure

    # gcc /mnt/t/mydir2/test.c # however gcc works without any hiccups

    # echo $?

    0

    Kind regards,
    one and zero
  • I'm sorry that it does not work, and that I don't know why. I don't think any of our test machines use xfs. We're going to have to figure out how to test this locally. In the meantime, I've submitted SDSCM00052014 to track this issue.

    How did you end up with such a large inode value?
  • Hi Archaeologist,

    I'm not sure why the inode is that big (maybe just a test value). However they use filesystems of more than 1TB ...
    and they ran into the issue in a real life situation originally.

    As for the reason of the error I found the following useful info:
    www.tcm.phy.cam.ac.uk/.../inodes64.html

    Kind regards,
    one and zero
  • EDIT: sorry ,didn't see that one and zero had already pointed to _FILE_OFFSET_BITS (and delete post doesn't work for me)

    Hi


    This sounds a lot like this bug report on redhat.com. Apparently, CGT was compiled without _FILE_OFFSET_BITS=64. I always thought _FILE_OFFSET_BITS=64 would only affect file size-related entities like off_t, but apparently it also changes the inode type. Without it, fstat and the like won't work for large inode values. Interesting.


    Markus