code run on PA-RISC and fails on itanium with core dump

[elaga]

Hi,
we are migrating from PA-RISC to itanium, and there are many jobs that run fine on PA-RISC and fails on itanium.
here is the example of C program:
void main()
{
SomeStruct a;
callFunc(a);
}

void callFunc(SomeStruct *a){};

I know that the problem is that we are not putting '&a', but just 'a' when calling to function callFunc from main. But why it works in PA-RISC? And maybe there is some possibility to make this code work on itanium without changing code itself? Thanks a lot

[Steven E. Protter]

Shalom,

You are going to need to keep a different code set for Itanium. Why does it work on one platform and not the other? Totally different CPU's and instruction sets.

SEP

[elaga]

So, you actually say that we need to rewrite our code.The problem is that there is too much problematic code. So, there is no hope to define memory use of itanium to be equivalent to PA-RISc?

[Geoff Wild]

Correct - there are many differences when making certain calls - especially at the hardware level.

That said, you could run the aries emulator if you don't want to update your code.

http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,8597,00.html

Rgds...Geoff

[A. Clay Stephenson]

It seems to me that your example is indefensible as it is very bad and sloppy code. You actually have to go out of your way for it compile without errors such as declaring a prototype without arguments. There is no way this code could function correctly regardless of the platform --- which is not to say that it might not run without crashing.

Problems like yours could compile perfectly in the days of K&R C where it was possible to
do absolutely insane things with nary a wimper from the compiler but even then there was no excuse for this kind of code because your makefiles should have run the code through lint. Even the most trivial code evaluation by lint would have found this kind of coding error and any modern ANSI C compiler easily detects these errors --- unless you intentionally outbushwhack yourself.

I don't know if you have baseball in your country but you need to find a baseball bat and use it on some developers --- and even if you could get this stuff to work on IA64 -- what are your plans for the next migration?


I know this is not what you wanted to hear but you will have a very difficult time refuting any of it.

[Dennis Handly]

What version of the IPF C compiler are you using? The latest is A.06.14.
http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,1743,00.html

There are several problems with your source. If you compile with +wlint you get:
warning #2951-D: return type of function "main" must be "int"
warning #4242-D: no prototype or definition in scope for call to "callFunc"
warning #2549-D: variable "a" is used before its value is set

And the most important is:
error #2159: declaration is incompatible with previous "callFunc" (declared at line N)
void callFunc(SomeStruct *a){};

warning #2381-D: extra ";" ignored

>But why it works in PA-RISC?

Because the PA32 procedure calling convention says the callee copies large by value structs, then passes an address. This was changed for PA64 and IPF to have the caller copy these large structs.

>And maybe there is some possibility to make this code work on Integrity without changing code itself?

No, you'll have to compile and fix all of your error 2159s. Since you didn't get error 2159, you may have to use the free download of cadvise that can do cross module analysis, since lint was removed on IPF.
http://www.hp.com/go/cadvise

>there is no hope to define memory use of itanium to be equivalent to PA-RISC?

Yes, the procedure calling conventions are completely different.

>Clay: There is no way this code could function correctly regardless of the platform

Unfortunately it works perfectly fine for PA32, if the struct is > 8 bytes. :-(
I saw that over and over again when customers ported to PA64.

[A. Clay Stephenson]

Then a pox a both of your houses because you both got it wrong ... and two wrongs don't make a right. In any event, clearly none of this code was subjected to any lint-like analysis --- and you are now paying for this lack of quality control that should have been deemed essential.

[Dennis Handly]

>Clay: Then a pox a both of your houses because you both got it wrong

I'm not sure if this was directed to the PA32 Procedure Calling Convention or to the original author? The PCC is just the innocent victim here :-), it is not in the enforcement business, just performance. If you want foolproof enforcement, there is Pascal and C++.

If your complaint is about the PA C compiler, as you mentioned, lint is available.