Wanted .DSF file format or .... may be disassembler for Alpha?

[Hoff]

---

Do you meant VMS-source listing ? I have V8.2 but did not found something about the .DSF file record structure/format.

---

You'd need to rummage the Linker and Debugger facilities on the source listings kit for details of the DSF files and related processing, and for any related SDL definitions files that might be available.  The DSF-related SDL definitions might be in one of those facilities, or might be stored over in one of the common facilities.

I wouldn't expect a whole lot of enlightenment from the DSF files in general, and if you don't have the matching DSF files for the executables involved, then this whole approach is probably a rock-fetch; not really worth the effort.

If you don't have the DSF files that were associated with the executable or the shareable image you're working on here, then you're headed toward using strings on and reversing the binaries.  

Even with a matching DSF, you're still necessarily going to be spending a whole lot of time and effort reversing the binaries.  Or spending time replacing the binaries, based on knowledge of the transformations that the binaries are providing.   The DSF can make reversing a binary a little easier, but it's still a complex and detailed project.

[Ruslan R. Laishev]

Ok, Hoff! I'll continue seaching in the listings ...

SRM_CHECK produce instruction listing, but w/o lines numbering and symbols has been stored in the .EXE file. I can see entry proints symbolic names in the DEBUG ...

[Hoff]

---

@Ruslan R. Laishev wrote:

Ok, Hoff! I'll continue seaching in the listings ...

SRM_CHECK produce instruction listing, but w/o lines numbering and symbols has been stored in the .EXE file. I can see entry proints symbolic names in the DEBUG ...

---

Um, and with no disrespect intended, so?   None of this is a surprise.    

Reverse-engineering on VMS isn't documented anywhere that I've seen.

Reverse-engineering is time-consuming and tedious, too.

You're going to learn more about the Alpha instruction set, and about the Alpha executable format.

In particular, you're going to have to learning the image formats and data structures, and then work through the executable code.  This takes a while, and the scope of the reversing project increases commensurate with the size of the binary.

See the Internals and Data Structures Manual for some information on the Alpha image headers.  The Alpha image header and related definitions are in the system libraries.  See the debugger symbol table (DST) stuff mentioned earlier for any latent DST records that might be present in the binary.  

If you don't have the corresponding DSF that was created with the binary file that you're looking at, then any discussions of the DSF don't seem particularly relevant — DSFs aren't instantiated out of thin air, and DSFs cannot be generated from existing binaries.

See the Alpha architecture reference manual (ARM) or the System Reference Manual (SRM) for details on the instruction set.

[abrsvc]

I will again mention about the instruction interleaving that happens on Alpha.  Assembly language instructions that pertain to a particular "line" of code can exist many assembly lines away from what seems to make sense.  Optimization of register usage along with instruction streaming causes register usage that may not make sense at first.

If the application is old enough, you may have better luck dis-asssembling a VAX executable image into MACRO32.  At least this approach would be little more straightforward.

Good luck,

Dan