I have built a shared object (.so) in Solaris 10, but cannot step
inside the functions in this library. The library is loaded at run time
and the address of the entry point function is obtained as below.

dllInstanceMR = dlopen("/usr/lib/libstorelib.so", RTLD_LAZY);
......
pfnProcessLibCommandMR = (ProcessLibCommandFunc)dlsym(dllInstanceMR,
"ProcessLibCommand");

Later while trying to step (using step command in dbx) into the
function pointed to by pfnProcessLibCommandMR, it executes the entire
function instead of steping inside.

The exact same code works fine (that is, steps inside) in case of
Linux.

The Makefile looks like this:
---------------------------------
LIB_VER=2.5

CFLAGS=-I$(SOLARIS) -I$(INC) -I$(INC_FW) -I$(INC_STORELIB)
-DSL_OS_SOLARIS -O -fPIC
LIB_VER_QUALIFIER = 1

SRC=../..
INC=../../../include
INC_FW=../../../../../../../../fw_fre/FW_SAS_MegaAPI
INC_STORELIB=../../../../../../../COMMON_StoreLib_Hdr
INC_PCI=/usr/include/sys

SOLARIS=../../SOLARIS

LIB_NAME = libstorelib.so.$(LIB_VER)-$(LIB_VER_QUALIFIER)

OBJS=slcommon.o sldebug.o slaenregister.o slaenprocessor.o sltopology.o
slsolaris.o

LIBS=-L/usr/lib -lpthread -ldl

all: storelib

storelib: /usr/lib/libstorelib.so

/usr/lib/libstorelib.so: $(LIB_NAME)
	rm -f /usr/lib/libstorelib.so*
	cp  $(LIB_NAME) /usr/lib/
	ln -sf /usr/lib/$(LIB_NAME) /usr/lib/libstorelib.so.1
	crle -u
	ln -sf /usr/lib/libstorelib.so.1 /usr/lib/libstorelib.so

$(LIB_NAME): $(OBJS)
	g++ -shared -Wl,-h,libstorelib.so.1 -o  $(LIB_NAME) $(OBJS) $(LIBS)

slsolaris.o: $(SOLARIS)/slsolaris.h $(SOLARIS)/slsolaris.cpp
	g++ -g $(CFLAGS) -c $(SOLARIS)/slsolaris.cpp

slcommon.o: $(INC_STORELIB)/storelib.h $(INC)/slinternal.h
$(INC_STORELIB)/slerrors.h $(INC_STORELIB)/types.h $(SRC)/slcommon.cpp
	g++ -g $(CFLAGS) -c $(SRC)/slcommon.cpp

sltopology.o: $(INC_STORELIB)/storelib.h $(INC)/slinternal.h
$(INC_STORELIB)/slerrors.h $(INC_STORELIB)/types.h
$(SRC)/sltopology.cpp
	g++ -g $(CFLAGS) -c $(SRC)/sltopology.cpp

sldebug.o: $(INC_STORELIB)/storelib.h $(INC)/slinternal.h
$(INC_STORELIB)/slerrors.h $(INC_STORELIB)/types.h $(SRC)/sldebug.cpp
	g++ -g $(CFLAGS) -c $(SRC)/sldebug.cpp

slaenregister.o: $(INC_STORELIB)/storelib.h $(INC_STORELIB)/slerrors.h
$(INC_STORELIB)/types.h $(INC)/slaenregister.h $(SRC)/slaenregister.cpp
	g++ -g $(CFLAGS) -c $(SRC)/slaenregister.cpp

slaenprocessor.o: $(INC_STORELIB)/storelib.h $(INC_STORELIB)/slerrors.h
$(INC_STORELIB)/types.h $(INC)/slaenprocessor.h
$(SRC)/slaenprocessor.cpp
	g++ -g $(CFLAGS) -c $(SRC)/slaenprocessor.cpp

clean:
	rm -f $(OBJS)
	rm -f libstorelib.so*
	rm -f /usr/lib/libstorelib.so*
--------------------------------

Thanks in advance.

googler wrote:
> I have built a shared object (.so) in Solaris 10, but cannot step
> inside the functions in this library. The library is loaded at run time
> and the address of the entry point function is obtained as below.
>
> dllInstanceMR = dlopen("/usr/lib/libstorelib.so", RTLD_LAZY);
> .....
> pfnProcessLibCommandMR = (ProcessLibCommandFunc)dlsym(dllInstanceMR,
> "ProcessLibCommand");
>
> Later while trying to step (using step command in dbx) into the
> function pointed to by pfnProcessLibCommandMR, it executes the entire
> function instead of steping inside.
>
> The exact same code works fine (that is, steps inside) in case of
> Linux.
>
> The Makefile looks like this:
> ---------------------------------
> LIB_VER=2.5
>
> CFLAGS=-I$(SOLARIS) -I$(INC) -I$(INC_FW) -I$(INC_STORELIB)
> -DSL_OS_SOLARIS -O -fPIC
> LIB_VER_QUALIFIER = 1
>
> SRC=../..
> INC=../../../include
> INC_FW=../../../../../../../../fw_fre/FW_SAS_MegaAPI
> INC_STORELIB=../../../../../../../COMMON_StoreLib_Hdr
> INC_PCI=/usr/include/sys
>
> SOLARIS=../../SOLARIS
>
> LIB_NAME = libstorelib.so.$(LIB_VER)-$(LIB_VER_QUALIFIER)
>
> OBJS=slcommon.o sldebug.o slaenregister.o slaenprocessor.o sltopology.o
> slsolaris.o
>
> LIBS=-L/usr/lib -lpthread -ldl
>
> all: storelib
>
> storelib: /usr/lib/libstorelib.so
>
> /usr/lib/libstorelib.so: $(LIB_NAME)
> 	rm -f /usr/lib/libstorelib.so*
> 	cp  $(LIB_NAME) /usr/lib/
> 	ln -sf /usr/lib/$(LIB_NAME) /usr/lib/libstorelib.so.1
> 	crle -u
> 	ln -sf /usr/lib/libstorelib.so.1 /usr/lib/libstorelib.so
>
> $(LIB_NAME): $(OBJS)
> 	g++ -shared -Wl,-h,libstorelib.so.1 -o  $(LIB_NAME) $(OBJS) $(LIBS)
>
> slsolaris.o: $(SOLARIS)/slsolaris.h $(SOLARIS)/slsolaris.cpp
> 	g++ -g $(CFLAGS) -c $(SOLARIS)/slsolaris.cpp
>
> slcommon.o: $(INC_STORELIB)/storelib.h $(INC)/slinternal.h
> $(INC_STORELIB)/slerrors.h $(INC_STORELIB)/types.h $(SRC)/slcommon.cpp
> 	g++ -g $(CFLAGS) -c $(SRC)/slcommon.cpp
>
> sltopology.o: $(INC_STORELIB)/storelib.h $(INC)/slinternal.h
> $(INC_STORELIB)/slerrors.h $(INC_STORELIB)/types.h
> $(SRC)/sltopology.cpp
> 	g++ -g $(CFLAGS) -c $(SRC)/sltopology.cpp
>
> sldebug.o: $(INC_STORELIB)/storelib.h $(INC)/slinternal.h
> $(INC_STORELIB)/slerrors.h $(INC_STORELIB)/types.h $(SRC)/sldebug.cpp
> 	g++ -g $(CFLAGS) -c $(SRC)/sldebug.cpp
>
> slaenregister.o: $(INC_STORELIB)/storelib.h $(INC_STORELIB)/slerrors.h
> $(INC_STORELIB)/types.h $(INC)/slaenregister.h $(SRC)/slaenregister.cpp
> 	g++ -g $(CFLAGS) -c $(SRC)/slaenregister.cpp
>
> slaenprocessor.o: $(INC_STORELIB)/storelib.h $(INC_STORELIB)/slerrors.h
> $(INC_STORELIB)/types.h $(INC)/slaenprocessor.h
> $(SRC)/slaenprocessor.cpp
> 	g++ -g $(CFLAGS) -c $(SRC)/slaenprocessor.cpp
>
> clean:
> 	rm -f $(OBJS)
> 	rm -f libstorelib.so*
> 	rm -f /usr/lib/libstorelib.so*
> --------------------------------
>
> Thanks in advance.

I still haven't been able to figure out how to step inside the code. I
am wondering if this information is going to be useful. When the
library function is getting called (through pfnProcessLibCommandMR), I
am actually getting a segmentation fault in one of the functions
(DiscoverCtrl) that it executes subsequently.

I get this error message in dbx:
t@1 (l@1) signal SEGV (no mapping at the fault address) in
__XXX_STORELIB__::DiscoverCtrl at 0xfec756d8
0xfec756d8: DiscoverCtrl + 0x0068: movl %eax, (%edx)

On Studio 11 GUI, the message it gives is:
Signal received: SIGSEGV (11) with sigcode MAPERR(1)
>From process: 0
>From program storelibtest, pid 820

I didn't think that the segfault has anything to do with not being able
to step inside the code, so I didn't give this information earlier. In
any case, if anybody can even tell me why this segfault is occurring,
that will be useful too. This is the second time in my code that the
library function is getting called; the first call completes
successfully (although it does not call the function DiscoverCtrl where
the segfault is taking place). This code was ported from Linux where it
works fine.

Any help will be greatly appreciated. Thanks.