#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include <errno.h>

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.

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.

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 <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include <errno.h>
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.

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.

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.

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.