reverse engineer aliases to symbol vectors

[SDIH1]

More out of interest, than an urging need:

On IA64, you can do an analyze/image/seg=all of
a shared library, and you find all symbol vectors in vector table order, and the aliases are just symbols with another name pointing to the same 'value' (procedure entry point). So you can easily reconstruct a symbol_vector option file for the linker from the ana/ima output.

On Alpha, you get the symbol vectors not in the order of the jump table, but the 'value:' field here is the offset from the beginning
of the jump table, so a sort gives you the vectors in jump table order.
Problem is that aliases can be identified by them having a procedure entry point of zero, and for data having a value of at least 64k.
But there is no way to find out to what procedure the aliases are pointing.

See attachment for relevant sections of analyze/image on IA64 and Alpha and the linker options file used to compile this (absolutely
useless) shareable image.

Questions:
- Does this imply aliases are implemented differently on Alpha?
- I am right in thinking that reverse engineering a symbol option file is not possible on Alpha?

[Hoff]

1: Yes.
2: No.

[John Gillings]

Jose,
With enough digging through data structures, most things are possible. It all depends on how much trouble you want to go to.

In this case, depending on what you're trying to achieve, it may not be necessary to worry about aliases at all.

I'm guessing that the reason you're trying to reconstruct a symbol vector is to create a replica shareable image to plug in place of the original? Similar to the output from my FAKE_RTL utility?

If that's the case, you can simply ignore the aliases. Just construct the symbol vector for the "real" symbols. This will give you a run time compatible image. The only discrepancy will be linking against your fake image from an image which references an alias (it will get USEUNDEF errors looking for the aliases). However, you can keep a copy of the original image and link against it to generate all the correct references. Substitute your image at run time.

[H.Becker · Accepted solution]

The latest set of VOIT (VMS Object and Image Tools) has this, maybe it's what you are looking for:

$ ../alpha/imgexp alias.exe
Image Exports (Alpha), version 1.5
DRIE, type is procedure, value: 0x20
EEN, type is procedure, value: 0x0
TRANSLATE_EN, type is data, value: 0x20000
TWEE, type is procedure, value: 0x30
VIER, type is procedure, value: 0x10
Translate_en, type is data, value: 0x20000
drie, type is procedure, value: 0x20
een, type is procedure, value: 0x0
twee, type is procedure, value: 0x30
vier, type is procedure, value: 0x10
$

The entries are printed in the same order as they appear in the symbol vector.

[SDIH1]

The reason was that I found that I had 6 versions of zlib (or libz) on one of my systems. A couple of other libraries were available in various flavours as well.

Not really a problem, but I was really curious what the differences were, and at the back of my mind I was contemplating maybe replacing a few of them by a more up-to-date version. Needless to say this is not a critical production system.

After looking at the analyze/image output on IA64, I was very optimistic, until I looked at the Alpha output.

What I saw on IA64 was the way I thought it would work: a simple addition to the symbol vectors pointing to the same procedure or symbol table offset.

I couldn't find any docs on how and why this was different on Alpha, hence my question.
Still curious how exactly this is different.

The imgexp tool provides exactly the information I was looking for, thanks mr. Becker!

[SDIH1]

For the few persons that are curious:
attached a command procedure in a saveset
that uses imgexp of mr Becker and produces a symbol_vector file. On Alpha this is correct, as on Alpha I know how to identify aliases from proper procedures, on IA64 I take a guess.
Good enough for me at the moment.

[SDIH1]

Closed.