<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic reverse engineer aliases to symbol vectors in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267868#M40984</link>
    <description>More out of interest, than an urging need:&lt;BR /&gt;&lt;BR /&gt;On IA64, you can do an analyze/image/seg=all of&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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&lt;BR /&gt;of the jump table, so a sort gives you the vectors in jump table order.&lt;BR /&gt;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.&lt;BR /&gt;But there is no way to find out to what procedure the aliases are pointing.&lt;BR /&gt;&lt;BR /&gt;See attachment for relevant sections of analyze/image on IA64 and Alpha and the linker options file used to compile this (absolutely&lt;BR /&gt; useless) shareable image.&lt;BR /&gt;&lt;BR /&gt;Questions: &lt;BR /&gt;- Does this imply aliases are implemented differently on Alpha?&lt;BR /&gt;- I am right in thinking that reverse engineering a symbol option file is not possible on Alpha?</description>
    <pubDate>Wed, 29 Dec 2010 19:08:54 GMT</pubDate>
    <dc:creator>SDIH1</dc:creator>
    <dc:date>2010-12-29T19:08:54Z</dc:date>
    <item>
      <title>reverse engineer aliases to symbol vectors</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267868#M40984</link>
      <description>More out of interest, than an urging need:&lt;BR /&gt;&lt;BR /&gt;On IA64, you can do an analyze/image/seg=all of&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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&lt;BR /&gt;of the jump table, so a sort gives you the vectors in jump table order.&lt;BR /&gt;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.&lt;BR /&gt;But there is no way to find out to what procedure the aliases are pointing.&lt;BR /&gt;&lt;BR /&gt;See attachment for relevant sections of analyze/image on IA64 and Alpha and the linker options file used to compile this (absolutely&lt;BR /&gt; useless) shareable image.&lt;BR /&gt;&lt;BR /&gt;Questions: &lt;BR /&gt;- Does this imply aliases are implemented differently on Alpha?&lt;BR /&gt;- I am right in thinking that reverse engineering a symbol option file is not possible on Alpha?</description>
      <pubDate>Wed, 29 Dec 2010 19:08:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267868#M40984</guid>
      <dc:creator>SDIH1</dc:creator>
      <dc:date>2010-12-29T19:08:54Z</dc:date>
    </item>
    <item>
      <title>Re: reverse engineer aliases to symbol vectors</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267869#M40985</link>
      <description>1: Yes.  &lt;BR /&gt;2: No.</description>
      <pubDate>Wed, 29 Dec 2010 19:37:53 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267869#M40985</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2010-12-29T19:37:53Z</dc:date>
    </item>
    <item>
      <title>Re: reverse engineer aliases to symbol vectors</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267870#M40986</link>
      <description>Jose,&lt;BR /&gt;  With enough digging through data structures, most things are possible. It all depends on how much trouble you want to go to.&lt;BR /&gt;&lt;BR /&gt;In this case, depending on what you're trying to achieve, it may not be necessary to worry about aliases at all.&lt;BR /&gt;&lt;BR /&gt;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?&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;</description>
      <pubDate>Wed, 29 Dec 2010 20:32:28 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267870#M40986</guid>
      <dc:creator>John Gillings</dc:creator>
      <dc:date>2010-12-29T20:32:28Z</dc:date>
    </item>
    <item>
      <title>Re: reverse engineer aliases to symbol vectors</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267871#M40987</link>
      <description>The latest set of VOIT (VMS Object and Image Tools) has this, maybe it's what you are looking for:&lt;BR /&gt;&lt;BR /&gt;$ ../alpha/imgexp alias.exe&lt;BR /&gt;Image Exports (Alpha), version 1.5&lt;BR /&gt;DRIE, type is procedure, value: 0x20&lt;BR /&gt;EEN, type is procedure, value: 0x0&lt;BR /&gt;TRANSLATE_EN, type is data, value: 0x20000&lt;BR /&gt;TWEE, type is procedure, value: 0x30&lt;BR /&gt;VIER, type is procedure, value: 0x10&lt;BR /&gt;Translate_en, type is data, value: 0x20000&lt;BR /&gt;drie, type is procedure, value: 0x20&lt;BR /&gt;een, type is procedure, value: 0x0&lt;BR /&gt;twee, type is procedure, value: 0x30&lt;BR /&gt;vier, type is procedure, value: 0x10&lt;BR /&gt;$&lt;BR /&gt;&lt;BR /&gt;The entries are printed in the same order as they appear in the symbol vector.</description>
      <pubDate>Wed, 29 Dec 2010 21:35:45 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267871#M40987</guid>
      <dc:creator>H.Becker</dc:creator>
      <dc:date>2010-12-29T21:35:45Z</dc:date>
    </item>
    <item>
      <title>Re: reverse engineer aliases to symbol vectors</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267872#M40988</link>
      <description>&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;After looking at the analyze/image output on IA64, I was very optimistic, until I looked at the Alpha output.&lt;BR /&gt;&lt;BR /&gt;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. &lt;BR /&gt;&lt;BR /&gt;I couldn't find any docs on how and why this was different on Alpha, hence my question.&lt;BR /&gt;Still curious how exactly this is different.&lt;BR /&gt;&lt;BR /&gt;The imgexp tool provides exactly the information I was looking for, thanks mr. Becker! &lt;BR /&gt;</description>
      <pubDate>Wed, 29 Dec 2010 22:28:45 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267872#M40988</guid>
      <dc:creator>SDIH1</dc:creator>
      <dc:date>2010-12-29T22:28:45Z</dc:date>
    </item>
    <item>
      <title>Re: reverse engineer aliases to symbol vectors</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267873#M40989</link>
      <description>For the few persons that are curious:&lt;BR /&gt;attached a command procedure in a saveset &lt;BR /&gt;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.&lt;BR /&gt;Good enough for me at the moment.</description>
      <pubDate>Thu, 30 Dec 2010 21:15:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267873#M40989</guid>
      <dc:creator>SDIH1</dc:creator>
      <dc:date>2010-12-30T21:15:00Z</dc:date>
    </item>
    <item>
      <title>Re: reverse engineer aliases to symbol vectors</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267874#M40990</link>
      <description>Closed.</description>
      <pubDate>Fri, 31 Dec 2010 12:23:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/reverse-engineer-aliases-to-symbol-vectors/m-p/5267874#M40990</guid>
      <dc:creator>SDIH1</dc:creator>
      <dc:date>2010-12-31T12:23:08Z</dc:date>
    </item>
  </channel>
</rss>

