• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 709 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler/TMS320C40: Need support on Tartan 2.1.1 compiler on Solaris 8

Roger Jeurninck
Prodigy 30 points
Part Number: TMS320C40
Other Parts Discussed in Thread: SYSCONFIG

Tool/software: TI C/C++ Compiler

Hi,

For one of our mature products we are moving from Solaris 8 bare metal hardware to a Solaris 8 branded zone solution. Unfortunately the compiler gives an unexpected error:

myhost:~ > tc foo.c
Tartan C Integrated Shell v2.1.1
Copyright (c) 1993-1995 by Tartan, Inc., All Rights Reserved
TC Shell: Unable to retrieve current working directory

It would really help if I could find out what OS call is being done by the tc binary which results in this output. Maybe someone has still access to the sourceode or does know a workaround for this issue?

thanks a lot,

Roger Jeurninck

  • 0
    TI__Expert 4930 points
    I don't know anything about that compiler, but Solaris 8 should have the "truss" command which can trace system calls.
  • 0
    TI__Guru**** 232700 points

    Roger Jeurninck said:
    Tartan C Integrated Shell v2.1.1

    Unfortunately, we don't support that compiler in this forum.  In the web searching I did, I could find apparent support for Tartan Ada compilers, but not Tartan C compilers.  Consider contacting the Tartan Ada folks.  They may know where to direct you.  However, at this point, you should be prepared for the possibility that no one supports this compiler.

    Roger Jeurninck said:
    It would really help if I could find out what OS call is being done by the tc binary

    I have used strace for this purpose.

    Thanks and regards,

    -George

  • 0 in reply to pf
    Prodigy 30 points
    Hi,

    thanks for the suggestion. I did already test this out but I could not get any meaning full hints out of it. Below two snippets of the TC compiler's truss output, unfortunately I cannot trace back the real call done (see below).

    What we did find out that the standard preloading done in the Solaris 8 branded zones (LD_PRELOAD=/usr/lib/secure/s8_preload.so.1) does introduce this issue. Without the preloading the problem does not occur. Most likely the functionality of the getcwd is changed within this s8_preload library.

    regards,

    Roger

    <---------- failing call on Solaris 8 branded zone ----------->

    .....

    552: open("/usr/platform/sun4v/lib/libc_psr.so.1", O_RDONLY) = 3
    552: mmap(0xFE7A0000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFE7A0000
    552: close(3) = 0
    552: close(4) = 0
    552: lwp_sigtimedwait(0xFFBFE9C0, 0xFFBFE880, 0x00000020) = 0
    552: lwp_sigtimedwait(0xFFBFE888, 0xFFBFE7B0, 0x00000010) = 0
    552: lwp_sigtimedwait(0xFFBFE7A0, 0xFFBFE888, 0x00000010) = 0
    552: sigaction(SIGPOLL, 0xFFBFE880, 0xFFBFE858) = 0
    552: lwp_sigtimedwait(0xFFBFE860, 0xFFBFE7B0, 0x00000010) = 0
    552: lwp_sigtimedwait(0xFFBFE7A0, 0xFFBFE860, 0x00000010) = 0
    552: lwp_sigtimedwait(0xFFBFE858, 0xFFBFEA40, 0x00000020) = 0
    552: sysconfig(_CONFIG_PAGESIZE) = 8192
    552: brk(0x00012A80) = 0
    552: brk(0x00014A80) = 0
    552: close(2) = 0
    552: getrlimit(RLIMIT_NOFILE, 0xFFBFEEC0) = 0
    552: fcntl(1, F_GETFL, 0x00000000) = 8193
    552: fstat64(1, 0xFFBFEDA0) = 0
    552: close(2) Err#9 EBADF
    552: fcntl(1, F_DUPFD, 0x00000002) = 2
    552: ioctl(1, TCGETA, 0xFFBFDFBC) Err#25 ENOTTY
    552: fstat(1, 0xFFBFDF48) = 0
    552: brk(0x00018A80) = 0
    TC Shell: Unable to retrieve current working directory

    <---------- succesfull call on bare metal ------------------>

    .....

    7938: open("/usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1", O_RDONLY) = 3
    7938: fstat(3, 0xFFBEE5BC) = 0
    7938: mmap(0xFE6E0000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFE6E0000
    7938: close(3) = 0
    7938: close(4) = 0
    7938: sigaction(SIGPOLL, 0xFFBEEBA0, 0xFFBEEC20) = 0
    7938: sysconfig(_CONFIG_PAGESIZE) = 8192
    7938: brk(0x00012A80) = 0
    7938: brk(0x00014A80) = 0
    7938: close(2) = 0
    7938: getrlimit(RLIMIT_NOFILE, 0xFFBEF0A8) = 0
    7938: fcntl(1, F_GETFL, 0x00000000) = 8193
    7938: fstat64(1, 0xFFBEEF88) = 0
    7938: close(2) Err#9 EBADF
    7938: fcntl(1, F_DUPFD, 0x00000002) = 2
    7938: ioctl(1, TCGETA, 0xFFBEE1A4) Err#25 ENOTTY
    7938: fstat(1, 0xFFBEE130) = 0
    7938: brk(0x00018A80) = 0
    7938: getrlimit(RLIMIT_NOFILE, 0xFFBEE9E0) = 0
    7938: pipe() = 3 [4]
    7938: vfork() = 7939

    ......
  • 0 in reply to Roger Jeurninck
    Prodigy 30 points

    Hi,

    as a workaround the LD_NOCONFIG environment variable will be set to "NONE"

    thanks for your support, thread can be closed

    Roger