Migrating our app from HP-UX PA-RISC to HP-UX 11.23 Integrity

[JaganKumar]

Core was generated by `odlcomp'.
Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object
#0 0xc0000000001d2b20:0 in strcpy+0x40 () from /usr/lib/hpux64/libc.so.1
(gdb) bt
#0 0xc0000000001d2b20:0 in strcpy+0x40 () from /usr/lib/hpux64/libc.so.1
#1 0xc000000005445d30:0 in OpenFile (file=0x9fffffffbf7f1940,
fn=0x9a50

) at clcomp.c:191
#2 0xc000000005444fc0:0 in ClCompile (kwlist=0x6000000000000370)
at clcomp.c:126
#3 0x4000000000005700:0 in main (argc=2, argv=0x9fffffffffffeae8)
at odlcomp.c:187

we are getting core dump here, i know that libc.a is no more in HP 11i but i am not sure how to check we new libc.sl lib file in 11i whether our code has to change to make compatible with new lib file. please clarrify.

[JaganKumar]

Sorry my question is how to check whether new libc.so.1 is compatible to our code which access libc.a in PA RISC machine.

[Andrew Young_2]

Hi.

Can you confirm that all you are doing is upgrading from HP-UX 11.00 to 11i or are you also moving from PA-RISC (rp or 900 series) to Itanium (rx-series)

What can you tell me about this app that you are currently using. Is it installed as binaries or do you have source or object code avialable for it?

Regards

Andrew Y

[JaganKumar]

we are migrating our HP-UX 11.o (PA-RISC) to 11i (itanium ELF). thing is we are not upgrading 11i is installed in new box. our application is in C which will interact with sybase15 earlier it was with sybase12. we were started copying binaries but it doesnt work. so we have to recompile all the binaries in new box.

when we compile we are getting the core dump. before this we have almost settled all libary mismatch for both the box.
Any input in this regard will be helpful. Thanks.

[Steven E. Protter]

Shalom,

You will probably need significant code changes to make this work. Oracle for example maintains a separate compile and probably code base for the same Os 11.23, PA versus IA-64.

Its debug and development time for the app more than likely.

SEP

[rick jones]

_Which_ 11i and with which compiler and version?

Anyhow, was the application 64-bit before on 11.0, or is this a 32-bit to 64 bit migration? Did the compiler emit any particular warnings about 64 bitness, or implied return values or the like?

Probably worth enabling the migration warnings available with the compiler.

Have you tried HP Cadvise on the source? (IIRC http://www.hp.com/go/cadvise)

[Dennis Handly · Accepted solution]

(It would be helpful if you mentioned you were migrating to 11.23 IPF or Integrity. The term "11i" doesn't have enough details.)

Your stack trace indicates you are trying to copy to a bad address. Either you are trying to write to a readonly string, or the address is just bad.
Do the following:
(gdb) p /x $r32
(gdb) x /8x $r32
(gdb) x /s $r33

You should also look at line 191 in clcomp.c to see what you are passing to strcpy.

>Rick: was the application 64-bit before on 11.0, or is this a 32-bit to 64 bit migration?

Right, a good question.
Compile with +w64bit and +wlint.

[JaganKumar]

Hi all, thanks for the response.

we found our make file is seeking some 32 bits lib files so once we provide relevant lib file of new box we got the core dump issue resolved.But one of our C file is accessing a paculiar lib file named libdbtraps.sl in the path /usr/local/lib. we are not sure whether the lib file belongs to unix or sysbase or application's.

I know /usr/local/lib is for OS lib files but HP tech support in India told us that it is not a Unix file.

Do any one aware of this lib file, please let me know.

[Duncan Edmonstone]

Well a quick google on libdbtraps.sl or libdbtraps or even just dbtraps turns up absolutely nothing! (that doesn't happen very often)

That suggests it might be something someone at your company developed themselves...

Maybe you can get a hint by running a what and a strings against it - the output might tell you something usefull about the lib:

what /usr/local/lib/libdbtraps.sl
strings /usr/local/lib/libdbtraps.sl

I guess a chatr and ldd might show up something interesting as well...

ldd /usr/local/lib/libdbtraps.sl
chatr /usr/local/lib/libdbtraps.sl

HTH

Duncan

[Dennis Handly]

>I know /usr/local/lib is for OS lib files but HP tech support in India told us that it is not a Unix file.

/usr/local/lib does NOT contain any HP-UX official libs. They are all in /usr/lib/.

>Duncan: Maybe you can get a hint

You can also use "nm -px" on the libs to see what functions are there.

[JaganKumar]

Thanks for your response.

we did what, strings, ldd and chatr, but we got

What - it just display

/usr/local/lib/libdbtraps.sl:


Strings - we got all the strings in the lib but we got this info with nm command itself.

ldd - this lib file is 32 bit and ldd throws error as 'invalid file type'.

chatr - returns some info, which we are not sure how to take it.

/usr/local/lib/libdbtraps.sl:
shared library
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path disabled first Not Defined
shared vtable support disabled
static branch prediction disabled
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
data page size: D (default)
instruction page size: D (default)

Out of this lib file in our code we are using some functions. we are trying to figure out the src for this lib file.

Is there any command which will find a word in given dir and its sub dir,so that we can give a find from / path.

[Dennis Handly]

>strings - we got all the strings in the lib but we got this info with nm command itself.

Did you use "strings -a"?

>we are trying to figure out the src for this lib file.

If you used HP's PA32 compilers, you could use:
$ odump -comp libdbtraps.sl
This will tell you the source filename and the compiler options.

>Is there any command which will find a word in given dir and its subdir, so that we can give a find from / path.

You mean using grep?
$ find path -exec grep -w -e string1 -e string2 ... +

[JaganKumar]

Thanks for your valuable comments.

No we are using Ansi C compiler for this migration. can we have any command which can get us the src file like odump?

and one more query, we have #ifdef MSC and declaration of some struct and varibles in the if block. we see this if condition is always failing and get undeclaration error for those variables and Structs.

we found in google that it is Microsoft C compiler in some links. but we are not sure about it. Is there any other possible value that might be get assigned to this MSC. or how to check this in old box? expecting your valuable comments.

[Dennis Handly]

>No we are using ANSI C compiler for this migration. can we have any command which can get us the src file like odump?

As I said, if you used HP's compilers (and didn't strip it) then you can use odump on your PA box:
$ /usr/ccs/bin/odump -comp libdbtraps.sl
If you used gcc, you are out of luck, unless you have debug info.

>we have #ifdef MSC ... we found in google that it is Microsoft C compiler in some links. ... Is there any other possible value that might be get assigned to this MSC.

It seems that MSC is Microsoft C. Some of our RogueWave headers test _MSC_VER.

[JaganKumar]

We found the same in some of the header. problem is the IF condition never goes true, so we are facing problem since some struct are declared into the if block.

how to check this whether MSC is compiler specific.

is there a possiblity that this might be there define in older version of Ansi C and some other variable for Ansi C V5.5?

[V. Nyga]

@rick,

could you please visit this one:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1126273

Volkmar

[Dennis Handly]

>how to check this whether MSC is compiler specific.

Look at some MS documentation?

>is there a possibility that this might be defined in older version of ANSI C and some other variable for ANSI C A.05.50?

Of course not. It is illegal for an ANSI C compiler to define any macros that are in the user's namespace. I.e. don't start with __ or _ uppercase.