1748338 Members
5206 Online
108762 Solutions
New Discussion юеВ

AEST

 
dennis cooper
Advisor

AEST

How do I find the information required to correctly build the .AIIF file for use with AEST? I have the list file from the aest/dump...
8 REPLIES 8
John Gillings
Honored Contributor

Re: AEST

Dennis,

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!)
A crucible of informative mistakes
dennis cooper
Advisor

Re: AEST

John,

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.
H.Becker
Honored Contributor

Re: AEST

Do you mean you can't link your native FORTRAN objects to the translated (_AV) shareable image?

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
pipe anal/image/section=symtab |search sys$input "symbol ", """"/match=and
?
dennis cooper
Advisor

Re: AEST

H.Becker,
Yes!
Results of your suggested command show all the "missing" objects in the Global Symbol Table. How do I get those recognized by my application?
John Gillings
Honored Contributor

Re: AEST

Dennis,

First learn as much about your shareable image as you can. Some simple things you can do without source code..

on Alpha:

$ 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?

A crucible of informative mistakes
H.Becker
Honored Contributor

Re: AEST

The LINK command and the linker messages should give a clue what's going wrong. I expect some USEUNDEFs. If there are none, then I would look at a /FULL/MAP/CROSS linker map and check for the symbols from the global symbol table of the RTL.

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.
John Gillings
Honored Contributor

Re: AEST

>You do not have to create a shareable image
>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.

A crucible of informative mistakes
H.Becker
Honored Contributor

Re: AEST

ANALYZE/IMAGE formats selectable pieces of the image. It produces a detailed output for the selected items. It uses much resources for its work. Running it once and searching for the wanted information seems good enough for me. And with a slightly different search command you can get more information about the global symbols.

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

and

$ 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
$