Uncharacteristic behavior of system call cs - Aix

This is a discussion on Uncharacteristic behavior of system call cs - Aix ; #include #include #include #include void foo(void * handle,const char *ptr) { void * symptr; if (NULL == (symptr = dlsym(handle, ptr))) { if ( 0 == errno) fprintf(stderr, "symbol %s not found\n", ptr); else perror(dlerror()); } else { printf("SYSTEM CALL ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Uncharacteristic behavior of system call cs

  1. Uncharacteristic behavior of system call cs

    #include
    #include
    #include
    #include

    void foo(void * handle,const char *ptr)
    {
    void * symptr;
    if (NULL == (symptr = dlsym(handle, ptr)))
    {
    if ( 0 == errno)
    fprintf(stderr, "symbol %s not found\n", ptr);
    else
    perror(dlerror());
    }
    else
    {
    printf("SYSTEM CALL : %s 0x%x\n", ptr, symptr);
    printf(" THE ADDRESS TO WHICH WE JUMP TO
    0x%x\n",*(int *)symptr);
    printf(" TOC VALUE(r2)
    0x%x\n\n",*(int *)((int)symptr + 4));
    }
    }

    int main()
    {
    void * handle;
    if ( NULL == (handle = dlopen("/unix",RTLD_NOW )))
    {
    perror(dlerror());
    exit(1);
    }
    foo(handle,"cs");
    foo(handle,"_getpid");
    foo(handle,"mkdir");
    foo(handle,"__unload");
    foo(handle,"thread_waitlock_");
    foo(handle,"skeytune");
    foo(handle,"kfork");
    if ( 0 != (dlclose(handle))) {
    perror(dlerror());
    exit(1);
    }

    return 0;
    }


    if you see the output on AIX 5.1 5.2 5.3 the value which we get for thr
    field THE ADDRESS TO WHICH WE JUMP TO is same for all other system
    calls except cs. If we do a dump -Tv -X64 /unix and grep for all the
    system calls the Scn field shows .data but for cs it shows .text. Can
    any one please explain this uncharacteristic behaviour of cs. I am not
    sure wether cs is a system call or not.


  2. Re: Uncharacteristic behavior of system call cs

    shankha wrote:
    > if you see the output on AIX 5.1 5.2 5.3 the value which we get for thr
    > field THE ADDRESS TO WHICH WE JUMP TO is same for all other system
    > calls except cs.


    cs() is not a system call.

    > If we do a dump -Tv -X64 /unix and grep for all the
    > system calls the Scn field shows .data but for cs it shows .text.


    Correct. cs() is implemented in millicode in low memory. Accessible
    from user space. No mode switch is required. You're misunderstanding
    the system. And no, this is not uncharacteristic. There are other
    routines implemented in this fashion as well.

  3. Re: Uncharacteristic behavior of system call cs

    When we try to access the address we get from dlsym call for cs we get
    a segmentation fault. Debugger shows the addess as not accessible.

    #include
    #include
    #include
    #include
    int main()
    {
    void * handle;
    void * symptr;
    int i;
    if ( NULL == (handle = dlopen("/unix",RTLD_NOW )))
    {
    perror(dlerror());
    exit(1);
    }

    if (NULL == (symptr = dlsym(handle, "cs")))
    {
    if ( 0 == errno)
    fprintf(stderr, "symbol cs not found\n");
    else
    perror(dlerror());
    }
    else
    {
    i = *(int *)*(int *)symptr;
    }
    return 0;
    }

    This does not happen for other system calls.The value which we get for
    *(int *)*(int *)symptr is a fixed value and is same for other calls.Can
    you please let me know why this is happening only for cs.

    This happens only on AIX 5.3 not on 5.2 and 5.1. On 5.1 and 5.2 the
    address is accessible.
    Gary R. Hook wrote:
    > shankha wrote:
    > > if you see the output on AIX 5.1 5.2 5.3 the value which we get for thr
    > > field THE ADDRESS TO WHICH WE JUMP TO is same for all other system
    > > calls except cs.

    >
    > cs() is not a system call.
    >
    > > If we do a dump -Tv -X64 /unix and grep for all the
    > > system calls the Scn field shows .data but for cs it shows .text.

    >
    > Correct. cs() is implemented in millicode in low memory. Accessible
    > from user space. No mode switch is required. You're misunderstanding
    > the system. And no, this is not uncharacteristic. There are other
    > routines implemented in this fashion as well.



  4. Re: Uncharacteristic behavior of system call cs

    shankha wrote:
    > When we try to access the address we get from dlsym call for cs we get
    > a segmentation fault. Debugger shows the addess as not accessible.


    > This happens only on AIX 5.3 not on 5.2 and 5.1. On 5.1 and 5.2 the
    > address is accessible.


    Well, that implies a problem with 5.3, doesn't it? What, _precisely_,
    is your kernel level? (lslpp -l bos.mp bos.mp64) And in all
    likelihood a fix will require an update to the latest levels. So
    you could start by applying (perhaps not committing, however) the
    latest kernel and see if the problem persists. Or search APARs
    for 5.3 kernel updates past whatever level you currently have.

  5. Re: Uncharacteristic behavior of system call cs

    outpuut of lslpp -l bos.mp bos.mp64

    Fileset Level State Description

    ----------------------------------------------------------------------------
    Path: /usr/lib/objrepos
    bos.mp 5.3.0.50 COMMITTED Base Operating System
    Multiprocessor Runtime
    bos.mp64 5.3.0.50 COMMITTED Base Operating System
    64-bit
    Multiprocessor Runtime

    Path: /etc/objrepos
    bos.mp 5.3.0.0 COMMITTED Base Operating System
    Multiprocessor Runtime
    bos.mp64 5.3.0.0 COMMITTED Base Operating System
    64-bit
    Multiprocessor Runtime


    Gary R. Hook wrote:
    > shankha wrote:
    > > When we try to access the address we get from dlsym call for cs we get
    > > a segmentation fault. Debugger shows the addess as not accessible.

    >
    > > This happens only on AIX 5.3 not on 5.2 and 5.1. On 5.1 and 5.2 the
    > > address is accessible.

    >
    > Well, that implies a problem with 5.3, doesn't it? What, _precisely_,
    > is your kernel level? (lslpp -l bos.mp bos.mp64) And in all
    > likelihood a fix will require an update to the latest levels. So
    > you could start by applying (perhaps not committing, however) the
    > latest kernel and see if the problem persists. Or search APARs
    > for 5.3 kernel updates past whatever level you currently have.



  6. Re: Uncharacteristic behavior of system call cs

    shankha wrote:
    > outpuut of lslpp -l bos.mp bos.mp64
    >
    > Fileset Level State Description
    >
    > ----------------------------------------------------------------------------
    > Path: /usr/lib/objrepos
    > bos.mp 5.3.0.50 COMMITTED Base Operating System
    > Multiprocessor Runtime
    > bos.mp64 5.3.0.50 COMMITTED Base Operating System
    > 64-bit
    > Multiprocessor Runtime


    Pretty sure it's a bug, but it doesn't appear to have been fixed.
    Report it.

+ Reply to Thread