- Integrated Systems
- About Us
- Integrated Systems
- About Us
10-12-2009 02:08 PM
On Alpha the .IIF files were created by executing the translated image, gathering information about the image, which could be fed back into the translation process to influence it based on actual use. In theory the mechanism could be used to improve performance over time, but I'm not sure it was ever really used.
On Itanium the .AIIF files are used for a different purpose. It's to do with remapping a routine from the translated image into another routine altogether. Obviously this is not something that can be automated, and only required when one or more routines in your Alpha shareable image to be translated misbehaves somehow. Perhaps it can't be translated, or it performs badly. Rather than reimplement ALL the routines in your source image, you reimplement just a few of them and revector those routines to your new (native) shareable image.
You could also use this as a mechanism to gradually reimplement a shareable image. Eventually your .AIIF file would have an entry for all routines in the source image, and you could switch to the native one.
Take SYS$SHARE:LIBRTL.AIIF as an example. Of the several hundred LIB$ routines, just a few of them need to be revectored, all related to (Alpha) INVO context. The new routines are implemented in a native shareable image called TIE$SHARE. The first column of numbers gives the symbol vector slot for the routine to be replaced, the second is the symbol vector slot of the new routine in the new image. Third column is the name of the new image.
How do you work out the symbol vector slot? I guess you have to count them!
If you don't have access to the original linker OPTIONS file, look up my FAKE_RTL tool and execute it against your source shareable image. One side effect is a symbol vector analysis (output into a file with a .VEC extension). The first column in that file is the symbol vector offset (in hex). Divide it by 8 to give you the vector slot number (since entries are 8 bytes).
In this particular example, I'm not sure what LIBRTL.AIIF is used for, as LIBRTL is not translated, but hopefully you get the idea.
You can also use the .AIIF file to fiddle with the GSMATCH criteria (though why you'd want to do that it a mystery to me!)
10-14-2009 05:01 AM
Thanks. I was way off base on this.
My problem is that I have an RTL with associated ACP on an Alpha which I have no source for. I need to move it to an Itanium. I have tried several iterations of AEST but still can't get my FORTRAN application LINKs to recognize the routines in the RTL. The translated ACP appears to run. The INSTAL of the RTL appears to be OK. The ACP and RTL facilitate communication with a Siemens H1 with S5 PLCs.
10-14-2009 08:41 AM
If that's the case, you probably have symbols shown by the linker USEUNDEF warnings. Can you compare/match them with those symbols shown in the output of
10-14-2009 09:05 AM
Results of your suggested command show all the "missing" objects in the Global Symbol Table. How do I get those recognized by my application?
10-14-2009 12:53 PM
First learn as much about your shareable image as you can. Some simple things you can do without source code..
$ LIBRARY/CREATE/SHARE tmp yourimage
$ LIBRARY/LIST/GLOBAL/NAMES tmp
This will show you all the symbols exported from your shareable image.
Now repeat against the _AV image in IA64. Are the lists the same?
Next try linking your program leaving out all mention of the shareable image. Capture the USEUNDEF symbols. Compare against the exported list.
Have you tried linking against a shareable image library containing your translated image? If not, please post the EXACT LINK command you're using, and the resulting error messages.
What logical names do you have defined to locate the shareable image?
10-14-2009 02:37 PM
You do not have to create a shareable image library to look at the global symbol table. ANALYZE/IMAGE is your friend. It works on Alpha as well as on I64. There are other unsupported tools as well, which can show the exported symbols and the exported PSECTs.
10-14-2009 03:06 PM
>library to look at the global symbol table.
>ANALYZE/IMAGE is your friend.
True, but ANALYZE/IMAGE generates lots of noise too (hence the piped SEARCH command). A shareable image library is fast, and shows just an unambiguous list of names exported from the image. And, you can use it to simplify linking.
10-15-2009 12:57 AM
Creating a library and letting librarian read the image to populate the library's GST, then printing the GST in a second run of librarian (and maybe deleting the library) seems more overhead to me.
Here, you can get the wanted information either way. If you need more, or want to look for exported PSECTs a library will not do the job.
There are unsupported fast tools which do not use much resources:
$ elfsym symvectypes.exe
ELF SYMbols, version 1.3
Type Bind Vis FuncType Linkage SectionNdx Name
OBJECT GLOBAL PROTECTED IGNORE 8 X
FUNC GLOBAL PROTECTED SYMV_IDX STD 8 FOO
FUNC GLOBAL PROTECTED SYMV_IDX STD 8 ALIAS
$ imgexp symvectypes.exe
Image Exports (I64), version 1.1
X, type is data, value is 0x10010
FOO, type is procedure, value is 0x40090
ALIAS, type is procedure, value is 0x40090
P, type is psect, value is 0x10000