AIX GL glue linkage assembler for custom dynamic linkage code.

This enhancement is specific to AIX and is a problem with the linker/binder software ('ld') and relates to the use of the GL storage mapping class within assembler files.

Micro Focus Visual COBOL uses some dynamically created assembler files in order to resolve an address at runtime the code for which does not exist when the calling code is compiled.

The mechanism we use to resolve this has been in use for over a decade but fails with recent linkers.

This RFE requests that previous behaviour is re-instated (use of [GL] storage mapping class in end-user provided assembler is allowed by the linker/binder) or perhaps that an alternative compatibile mechanism be provided.

It is important to note that the target callee code may not be native code, thus the resolved address might be an interpreter, or a custom loader, or native code such as is present in the demo.

The remainder of this description describes the mechanism by which a call is resolved at build time and at run-time.

The call proceeds as follows.

Something in the main program, (caller.c : main() in the demo) calls something, ('callee()' in the demo).
The actual target wanted is not and cannot be known at build time, thus the target code is not linked in at this time.

This call is resolved at build time to either 'xldyn_callee.s' (statically) or 'preload_callee.s' built into a linked shared object. In the real system
these assembler files are created 'on the fly'.

At runtime, these call into our runtime system (in the demo to 'caller.c : the_dynload()') which gets some address we really want to go to, whether an interpreter or direct native code or whatever.

The address is returned to the assembler and xldyn_callee.s or preload_callee.s (they are very similar) then branch to that address.

Thus if the final target is debugged (callee.c : callee() ) it sees the main 'caller' (main() within caller.c in the demo) as its immediate caller. There is nothing between them on the call stack.

Note that is is not possible (as has been suggested) to use a dynamic object (ld -brtl) to resolve the initial call to 'callee' because the end-user is expecting a single executable to be produced, not multiple files.

The xldyn_callee.s and preload_callee.s assembler files use '[GL]' glue linkage to reach the runtime (the_dynload in the demo) to get the wanted address to branch to. They are not '[PR]' and the mechanism does not work if the storage mapping class is changed to PR.

The demo created 3 executables (older versions of this demo had 4, but one is superfluous).

- callerLD - The problematical executable - linked (statically) with xldyn_callee.s AND preload_callee.s (in libprestub.so). This crashes (SEGV or Illegal instruction) if built with a later linker. I have version ld: LD 1.65.6.6 (4/1/14), though I believe there is more to this that just the linker version.

- callerX - statically linked only with xldyn_callee.s - works every time, thus demonstrating that 'xldyn_callee.s' works.

- callerP - linked with libprestub.so which contains 'preload_callee.s', also works, thus preload_callee.s works.

If callerLD is debugged on a failing system and single stepped it can be seen calling 'callee()' from 'main()' and executing some glue code injected by the linker which then jumps off to a junk location and fails - without ever hitting any more of the demo code.

The linker at no point warns of invalid code when the executable is built. If there is a problem, it should give a warning.

The linker behaves differently when only one of the 2 assembler files is linked (it works in those cases).