Problems Attaching to C++ Image using "adb"

[Bill Brown_5]

Hi ...

Environment:
HP ZX200 Itanium
HP-UX 11.23
aCC: HP ANSI C++/C B3910B A.05.36 [May 20 2002]

When attempting to attach to a running C++ image using "adb" I get the following error from "adb" and "adb" bails.

jadgews2 scm:adb -P 1436 ./APL_SPAWN_SERVER_IMAGE
Attached to process 1436
Current Process is 1436
adb: warning: /usr/lib/hpux32/libcl.so.1: Cannot locate unwind table ...
adb: warning: /usr/lib/hpux32/libcl.so.1: Stack backtrace may fail.
ttrace: TT_PROC_RDDATA: Bad address
jadgews2 scm:

Attaching to a C image works, meaning I do not get a "ttrace" error, I remain in "adb" allowing me to debug.

Any ideas?

Compile options use:

CPP="/opt/aCC/bin/aCC -c -AA +O2 -g -D_POSIX_C_SOURCE=199506L -D_HPUX_SOURCE -I$INCLUDE_DIR"

Link Options:

LINK_OPTS="-Wl,+noenvvar,+b,/usr/lib/hpux32,+nodefaultrpath,-B,immediate -lpthread -lcl -lrt -lCsup"

Thanks for any suggestions that may help.

Bill Brown

[harry d brown jr]

I had a similar issue with the unwind library, but with a different application, and I ended up creaking these links to satisfy the issue (I don't know if they will work for you):

ln -s /usr/lib/hpux32/libunwind.so.1 /usr/lib/hpux32/libunwind.so
ln -s /usr/lib/hpux64/libunwind.so.1 /usr/lib/hpux64/libunwind.so


lrwxr-xr-x 1 103 191 16 May 12 10:03 /usr/lib/hpux32/libunwind.so -> ./libunwind.so.1
lrwxr-xr-x 1 103 191 16 May 12 10:06 /usr/lib/hpux64/libunwind.so -> ./libunwind.so.1


live free or die
harry d brown jr

[Bill Brown_5]

Hello Mr. Harry Brown ...

Thank you very much for your reply. But I'm sorry to say your suggestion had no effect. In fact, the link to the "unwind" library already existed on my development machine (the platform where compiles and links are done).

Iâ m working with what I call â near real-timeâ applications involving a development organization of 50+ SW engineers. At times we will have an application failure due to a process going into an infinite loop and â adbâ allowed us a â lite-weightâ available means to dump the call stack in order to get an idea where in the application the failure was occurring. On a PA-RISC target this technique worked reliably and was very useful to us. But on the IA64 weâ ve been less successful.

One option Iâ m considering now is to push â gdbâ to each of the target machines and change my debug utility to reference â gdbâ rather than â adbâ . â gdbâ does support what I want to do, Iâ ve tested this. Even though â gdbâ is a GNU product (ie. free), Iâ m not 100% sure Iâ m able to distribute it since itâ s bundled with HP â aCCâ development product. But I think Iâ m OK if I simply install only the â gdbâ image on each of my target machines and nothing else associated with the â aCCâ product. But Iâ ll check with our HP rep before I do anything.

Question: Are the â unwindâ warnings from â adbâ related to the â ttraceâ failure (BAD ADDRESS)? Or are these two separate i