lib$find_image_symbol

[Klaus Heim]

I have a question to lib$find_image_symbol. I have written the following test program (fis.c).

/*
// Example of LIB$FIND_IMAGE_SYMBOL call.
// Dynamic image activation...
*/
#include
#include
#include
#include
#include
#include
#include
#include

typedef struct dsc$descriptor_s DSC_S$TYPE;

#define SIG_ARGS = 0
#define SIG_NAME = 1

int handler(int *sig, int *mech)
{
int i;
char time_string[23+1];
#pragma nostandard
$DESCRIPTOR(descr,time_string);
#pragma standard

if(sig[1]==LIB$_EOMWARN) return(SS$_CONTINUE);
if(sig[1]==SS$_UNWIND) return(0);

sys$set_return_value(0,0,sig[1]);
sys$unwind();
return(0);
}

int dynCall(DSC_S$TYPE *self, DSC_S$TYPE *target, DSC_S$TYPE *image)
{
int status;
int *addr;

lib$establish(handler);
status = LIB$FIND_IMAGE_SYMBOL(self, target, &addr, image);
lib$revert();
if(status & 1)
{
fprintf (stdout, "lib$find_image_symbol() %%X%08.08X\n", status);
fprintf (stdout, "name=%.*s addr=%%X%08.08X\n",
target->dsc$w_length,target->dsc$a_pointer,addr);
}
return(status);
}

main(int argc, char *argv[])
{
int status;
char name[80];

$DESCRIPTOR( self, "DLS$DIASHR" );
$DESCRIPTOR( image, "DLS$SHARE:.EXE" );
$DESCRIPTOR( target, "DIA$WA_GESAMT" );

if(argc > 1)
{
/*
argv[0] image
argv[1] first parameter
*/
memset(&name[0],0,sizeof(name));
strcpy(&name[0],argv[1]);
target.dsc$w_length = strlen(name);
target.dsc$a_pointer = &name[0];
}

status = dynCall(&self,&target,ℑ);
if(status & 1)
{
}
else
{
lib$signal(status);
}

return SS$_NORMAL;
}

To start the image i define the foreign command fis:==$sys$login:fis. Example:

$ fis
lib$find_image_symbol() %X00000001
name=DIA$WA_GESAMT addr=%X0006D890
$ fis dia$wa_kunde
lib$find_image_symbol() %X00000001
name=dia$wa_kunde addr=%X0006DD98
$

On Alpha I get "key not found in tree" error message for any unknown "symbol". But on IA64 the image hang. I got no message - the image is in LEF.

On IA64 I must link the shareable image pthread$rtl to fis.obj. Then I get the expected error message.

[H.Becker]

At the moment I can't explain why your test behaves differently on Alpha and I64.

But it looks like you want to ignore EOMWARN (compilation warnings in module 'module') messages.

lib$fis signals and returns the status. You can change your handler to ignore everything.

You can use lib$sig_to_ret as your handler.

But you can also fix the real problem and eliminate the warning(s) in the sharable image.

Which VMS version(s)?

How do you link?

[H.Becker]

Correction, here you can't use lib$sig_to_ret as your handler: it won't ignore the LIB$_EOMWARN.

[Klaus Heim]

System Version is V8.3-1H1.

Linker Command:

link fis_1
or
link fis_1,sys$input/opt
sys$share:pthread$rtl/share

I have found some new information. The problem is in my shared library dls$diashr.exe. With this library the program hang. This can also reproduced with the following system shared libraries:

$ define/process dls$diashr sys$share:cma$tis_shr
$ fis a
-> error message

$ define/process dls$diashr sys$share:pthread$rtl
$ fis pthread_create
-> ok
$ fis a
-> hang

In my opinion the handler is not the problem, but I will change it if you want.

[H.Becker]

Which smells like a known limitation. I don't know all the details out off the top of my head, but lib$fis is not reentrant: a second lib$fis will hang. It may be related to image initialization of the pthread$rtl.

Is your shareable image linked against pthread$rtl?

I think the lib$fis limitation was/is documented, but I do not know where.

[Richard J Maher]

Hi Klaus,

As unhelpful as it sounds, I would go for an AST-threaded main process (e.g. a communication server) that schedules work on a variable number of single-threaded execution servers (worker pool min, max, idle-timeout etc)

Alternatively use JAVA.

OK, completely useless I know; on the plus side here's an example of a handler that sorts out a lib$fis EOMWARN for you: -

identification division.
program-id. t3$$cond_hndlr.
*
data division.
working-storage section.
01 ss$_normal pic s9(9) comp value external ss$_normal.
01 lib$_eomwarn pic s9(9) comp value external lib$_eomwarn.
01 ss$_resignal pic s9(9) comp value external ss$_resignal.
01 ss$_continue pic s9(9) comp value external ss$_continue.
01 ss$_unwind pic s9(9) comp value external ss$_unwind.
01 ss$_debug pic s9(9) comp value external ss$_debug.
01 sys_status pic s9(9) comp.
01 hndlr_status pic s9(9) comp.
*
01 match_pos pic s9(9) comp.
*
linkage section.

01 sigargs.
03 sigarg_cnt pic s9(9) comp.
03 sigarg_elem pic s9(9) comp occurs 1 to 256 times
depending on sigarg_cnt.

01 mechargs.
03 mecharg_cnt pic s9(9) comp.
03 mecharg_frame pic s9(9) comp.
03 mecharg_depth pic s9(9) comp.
03 mecharg_r0 pic s9(9) comp.
03 mecharg_r1 pic s9(9) comp.

procedure division using sigargs, mechargs giving hndlr_status.
kick_off section.
00.
call "lib$match_cond"
using sigarg_elem (1),
lib$_eomwarn,
ss$_unwind,
ss$_debug
giving match_pos.

evaluate match_pos
when 1 move ss$_continue to hndlr_status
perform output_messages
when zeros move ss$_resignal to hndlr_status
perform output_messages
call "lib$sig_to_ret" using sigargs, mechargs giving sys_status
if sys_status not = ss$_normal
call "lib$stop" using by value sys_status
end-if
when other move ss$_resignal to hndlr_status
end-evaluate.
*
fini.
exit program.
*
output_messages section.
00.
subtract 2 from sigarg_cnt.
call "sys$putmsg" using sigargs by value 0, 0, 0.
add 2 to sigarg_cnt.
*
fini.
*
end program t3$$cond_hndlr.

Cheers Richard Maher


PS. Also helps for signalling (honouring) ss$_debug. I think the mechargs are cactus cross-platform but who needs 'em?

PPS. If you don't wish to re-invent the wheel again then there's always Tier3!

[Richard J Maher]

Forgot to mention how to register the condition handler before calling lib$fis: -

call "lib$establish" using by value t3$$cond_hndlr.

IIRC it was Alpha that turned this Frame Pointer modification from a run-time option to a quasi-compile-time thingy but the John Reagan's of this world would be much better suited to describing the details.

Cheers Richard Maher

[Klaus Heim]

H. Becker> The shareable image dls$diashr is not "directly" linked against pthread$rtl. dls$diashr uses fhshr and this image is linked against adaliblnkx which is linked against pthread$rtl.

Richard J Maher>I'm sorry but I did not unstand the message of your posting. I also had no Cobol compiler nor did I understand the Cobol program. Could you please explain it.

[H.Becker · Accepted solution]

Directly or indirectly doesn't matter, here: your image is linked against pthread$rtl. And you need to link the image with the lib$fis call to avoid this problem.

I suspect on the Alpha side, your shareable image is not linked against pthread$rtl.

Google found this note, in the OpenVMS Version 7.1 Release Notes:

V6.2

Applications that use thread-safe run-time libraries might not be able to use LIB$FIND_IMAGE_SYMBOL to dynamically activate DECthreads or products that depend on DECthreads.

Certain run-time libraries use conditional synchronization mechanisms. These mechanisms typically are enabled during image initialization when the run-time library is loaded only if the process is multithreaded. If the process is not multithreaded, the synchronization is disabled.

If the application dynamically activates DECthreads, any run-time library using conditional synchronization may not behave reliably.

To work around this problem, link the image that calls LIB$FIND_IMAGE_SYMBOL against PTHREAD$RTL.

[Klaus Heim]

On Alpha the image is not linked against pthread$rtl. Thats right.

I think, that's solution. Thank you for your help.

[Sandeep Ramavana]

Hi Klaus,

As Hartmut already pointed out, you cannot dynamically load pthread$rtl. If the main image is linked with the threads library (either directly or indirectly), the loader inserts an extra pthread$rtl frame before calling the "main" of the program. This is required to save some context. This would not be possible if you dynamically load pthread$rtl (since "main" would already have been called by then). Also few other components (like CRTL) depends on whether threading is enabled in the process during initialization. It would not recognize a change in state at a later point of time.

Best Regards,
Sandeep

[Sandeep Ramavana]

More details are available in the "Guide to POSIX threads" document.

http://h71000.www7.hp.com/doc/73final/6493/6101pro_031.html#vms_dynam_activ_sec

Or in the release notes of OpenVMS V8.3-1H1

http://openvms.compaq.com/doc/83final/ba322_90076/6676pro_005.html (Section 3.23)

Best Regards,
Sandeep