Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-12-2009 11:32 AM
тАО10-12-2009 11:32 AM
AEST
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-12-2009 02:08 PM
тАО10-12-2009 02:08 PM
Re: AEST
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!)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-14-2009 05:01 AM
тАО10-14-2009 05:01 AM
Re: AEST
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-14-2009 08:41 AM
тАО10-14-2009 08:41 AM
Re: AEST
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
?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-14-2009 09:05 AM
тАО10-14-2009 09:05 AM
Re: AEST
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-14-2009 12:53 PM
тАО10-14-2009 12:53 PM
Re: AEST
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-14-2009 02:37 PM
тАО10-14-2009 02:37 PM
Re: AEST
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-14-2009 03:06 PM
тАО10-14-2009 03:06 PM
Re: AEST
>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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-15-2009 12:57 AM
тАО10-15-2009 12:57 AM
Re: AEST
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
$