Hi Roland, When the "system call entry point" error is encountered, features like target function call will not work either. Does target function call work ? I assume you are using dbx 7.4 (117845-01) on Solaris 10 x86.
Please send me a tar ball of binaries and the ourput of "cat /etc/release". I'll investigate. Thanks, -Leonard Roland Mainz wrote On 06/06/06 17:15,: >Leonard Li wrote: > > >>>This is slightly offtopic, but due lack of a dbx-related mailinglist and >>>because it happens while debugging ksh93 I am dropping it here for now: >>> >>>While trying to debug ksh93 with "check -leaks" and/or "check -memuse" >>>dbx (version "Sun Dbx Debugger 7.4 117845-01 2005/03/05") simply crashes >>>like this: >>>-- snip -- >>>% env - SHELL=$SHELL TERM=$TERM HOME=$HOME EDITOR=$EDITOR >>>/opt/onbld/bin/bldenv ./opensolaris.sh >>># build the OS/Net B37 tree where ksh93 has been integrated >>>% cd /home/test001/ksh93/on_build1/test1/usr/src/lib/libshell >>># run dbx like this: >>>% (LD_LIBRARY_PATH=$ROOT/lib dbx ../../cmd/ksh/i386/ksh) >>>(dbx) check -memuse >>>(dbx) run -o emacs >>>run -o emacs >>>Running: ksh -o emacs >>>(process id 19500) >>>Reading rtcapihook.so >>>Reading libdl.so.1 >>>Reading rtcaudit.so >>>Reading libmapmalloc.so.1 >>>Reading libgen.so.1 >>>Reading rtcboot.so >>>Reading librtc.so >>>RTC: Enabling Error Checking... >>>dbx: can't find a system call entry point -- program not linked with >>>libc? >>> >>>dbx: internal error: signal SIGSEGV (no mapping at the fault address) >>> >>> >[snip] > > >>>... and again no success... ;-( >>> >>>Does anyone have a suggestion what I can do at this point to get "dbx"'s >>>"check -leaks / -memuse" functionality working on i386 ? >>> >>> >>RTC is depended on libc.so for various reason. In this case, it tries to >>locate an special instruction (lcall, sysenter or syscall) but fail to >>find one. A workaround is to include functions like close(), >>sigpending() or setuid() in your customized libc and make sure one of >>these instructions is used in those functions. >> >> > >Uhm... the problem is that this is no custom libc - it's just the libc >version in my B37 workspace which is almost identical to the one on the >CD - except the detail that I compiled it from source (using Sun Studio >10+recommended compiler patches). >I even copied /lib/libc.so.1 (after unmounting /libc/libc.so.1 to get >rid of the hardware-optimizsed version) to the proto/root_i386/ >workspace with the same result - which means the dbx problem occurs even >when both libraries are identical - at which point I assume that dbx >somehow does not like to use libraries referenced via LD_LIBRARY_PATH >... ;-( > >... and I need help with this catch22 - I cannot successfully hack&test >any RTC patches for libast without getting this part running... >heeellllppp... ;-( > >---- > >Bye, >Roland > > >
