Problem with lib$spawn when compiling with pointer_size=64

[#1]

Hi All,

Recently we have compiled our product with 64 bit when we found lib$spawn is not working properly with 64 bit pointer size.

I have written a small C program below to show the problem:

********************************************
TEST_LIBSPAWN.C
********************************************

void spawn_ast(int *);
void main()
{
$DESCRIPTOR64 ( command, "show time");
int *astprm, flags = CLI$M_NOWAIT;

astprm = (int *) malloc(sizeof(int));
*astprm = 10;

lib$spawn( &command, 0, 0, &flags, 0, 0, 0, 0 , &spawn_ast, (unsigned)astprm );
sleep(1);
}

void spawn_ast( int * astprm )
{
printf("%d\n\n",*astprm);
}

********************************************

When we compile and build the image as:

cc TEST_LIBSPAWN.C
link TEST_LIBSPAWN
run TEST_LIBSPAWN

everything works fine and the output is:

20-JAN-2009 12:09:26
10

But when I compile as pointer_size = 64 and run the image, it give some absurd value at the memory address being passed to lib$spawn at astprm:

cc TEST_LIBSPAWN.C /pointer_size=64
link TEST_LIBSPAWN
run TEST_LIBSPAWN

and the output is:

20-JAN-2009 12:10:52
538902529


Could anyone help me to know did i do anything wrong? and if not then why the value at address of "astprm" is getting changed from "10" to some absurd value "538902529".

Regards,
ajaydec

[Joseph Huber_1]

You are passing in the astparam argument an integer casted from a pointer. I just wonder why it results in the right value when compiled with 32 bit addresses.

Change all "int *" to "int" in the ast routine declarations, and
pass *astprm instead of (unsigned)astprm , and You will see what You want, namely the parameter value, not the truncated address.

If Your intention is really to pass an address as a parameter, then no, it is not possible with 64-bit pointers, since lib$spawn expects a longword by value in the astprm argument.

I see that help for lib$spawn mention "typically" the usage for passing a pointer, but should be updated to mention the 32-bit restriction.

[Joseph Huber_1]

Ah sorry, I should not have wondered why it works with 32-bit pointers :-)
An unsigned integer of course can hold a full 32-bit address.
But the explanation for 64-bit pointers holds.

[#4]

Hi Joseph,

Thanks a lot for your reply. My intention is to pass an address of a structure as a parameter. Since we can not pass 64-bit address is there any other means we can achieve it.

Regards,
ajaydec

[Joseph Huber_1]

As long lib$spawn is like that, no, I don't see a way to pass 64-bit items to the AST.

What You could do is to pass a 32-bit index in a global array of pointer to structures.
Or, if the number of such structures cannot be limited to a maximum, build a linked list of (identifier,pointer), pointer to the list-head in a global variable, and pass the identifier to the AST.

[Martin Vorlaender]

Ajaydec,

you can explicitly use the _malloc32 routine to request a 32-bit address for the AST parameter.

cu,
Martin

[Joseph Huber_1]

>>explicitly use the _malloc32 routine to request a 32-bit address for the AST parameter.

But...I think ajaydec has a reason to use 64 bit addressing, e.g. the workspace passed to the AST is a big one allocated in 64 bit space.

The simple test example is not the final project I assume.

[Hein van den Heuvel]

Agreed, while the documentation clearly mentions "longword" it really sets you up for failure with the words: "Typically, the varying-AST-argument argument is the address of a block of storage the AST routine will use."

Martin's suggestion of using an explicit _malloc32 is fine. The control block passed can contain the pointer to the real work block to be used. Joseph's suggestion to pass a 32-bit index (or hash) of sort is of course fine as well. That's how OpenVMS channels and RMS rabs & fabs work through the ifi/isi word.

Irronically, when I quickly compiled this on my Itanium system, the malloced address actually happened to fit in 32 bits.
But it was sign extended into an 64 bit address which happened to be valid.
Bad luck! It should have been an ACCVIO which possibly would have been more clear.

For jucks... this 'works'.

void spawn_ast( unsigned int my_astprm )
{
int *astprm;
(unsigned long long) astprm = my_astprm;
printf("%Lx : %d\n\n", astprm, *astprm);
astprm = (int *) my_astprm;
printf("%Lx : %d\n\n", astprm, *astprm);
}
:
80000010 : 10
ffffffff80000010 : 278557

Of course it does not really work, it was just coerced to pretend to work. The compiler tries to warn!

Cheers,
Hein.

[Hoff]

Ayup, looks like this is working as originally designed and not working quite as well as intended in the 64-bit land of V7.0 and later. The doc looks to be pre-V7, too.

Log a bug report with HP.

Looks like this might need lib$spawn_64.

As for the case here...

Use hash or a 32-bit allocation or such.

Or use sys$creprc with LOGINOUT, et al. There's a termination mailbox here, too.

Or don't use lib$spawn; invoke an image in a process or subprocess directly.

Or use sys$sndjbcw et al.

Or use DECnet task-to-task or other such; there are a gazillion ways to create a process.

Or use APIs that might be available for whatever the task at hand; I've seen more than a few lib$spawn calls that could be replaced with direct API calls over the years. Some of this DCL stuff gets written in antiquity, and never looked at again and never compared against what (new) APIs might be available on OpenVMS.

If you find yourself in a hole, don't keep digging.

[John Gillings]

ajaydec,

>My intention is to pass an address of a
>structure as a parameter. Since we can not
>pass 64-bit address is there any other
>means we can achieve it.

As you now know, astprm arguments in most places are 32 bit objects. Since you're in control of both sending and receiving side, it's entirely up to you what that object means.

Although it's a bit ugly, you can still pass a 64 bit address, indirectly. Allocate a 64 bit block in 32 bit address space, using _malloc32. Load it with your 64 bit address, then pass the 32 bit address of the block as astprm. In your ast routine, follow the 32 bit pointer to retrieve the 64 bit pointer.

[#11]

Hi All,

Thanks a lot to everyone for your valuable time and thoughts.

Problem got resolved by using _malloc32 for that particular call.

Regards,
ajaydec