Unused Symbols Scanner

Unused Symbols Scanner  .

Presentation

This tool is for the last minute release of your application. It can be used to remove test-variables, redundant code and data, or dead-code coming with a Disassembly.

You have access to the Dialog, after a F5 compilation, by clicking the [Orphan List] Button. Once executed, this dialog is automatically closed and re-opened, with each Compilation, for assuming the in-between updates, until you close it by yourself.

How to use it

The scanner displays two lists, One for Code labels and One for Data labels. Since RosAsm reserves a section for data, and a section for code, it can tag what is data and what is code. 

The Unused Symbols Dialog cannot make any automatic deletions. This is your job to do the clean-up, carefully and step by step, because the symbols are not guaranteed to be 100% correctly listed. For instance, there is no way for RosAsm to determine, with 100% accuracy, when a routine ends. A routine can have any number of exits and, also many different labels can point to it. Many similar labels can tag the same data. 

Example:

StringToInteger:

    mov eax D$eax+String.Pchar

PcharToInteger:

    ..............

ret

Maybe you wrote something like the above. Even when calling only the first label, the 'PcharToInteger' may report it as unused. But, the code cannot be deleted, so we need to interactively verify each label before deleting Code.

In practice

Using the Symbols Scanner is easy. Just double click a label, and let RosAsm move you to the label declaration. Take a look at the code. Is it OK to delete it? If ‘Yes’, then select the code and delete it. Then, do the next label. It is as simple as that.

Now, a few tips to help you with this work that, regretfully, can be quite tedious and boring.

Work on a copy of your application when using the scanner.

You can save (and confirm) your changes, by pressing F5 or F6. If it went badly, use Ctrl-Z to undo.

Do not kill too much of the source unless you are sure you can do it, before you press F5.

Do Code first

(Make sure to activate the Editor window when pressing F5/F6. RosAsm will automatically close the Symbols Scanner and re-open it after the compile).

Clearing of Disassemblies

 

When you have an up and working Disassembly, it is usual to have dead Code and/or dead Data inside.

When the Disassembler's Recognitions jobs are over, everything, that is not found to be valid Code, and that is left un-identified, is considered to be Data.

 For example, in the Resources Section, if there is a Resource Type that RosAsm does not assume - typically the Version Resource -, these materials will be given, in the outputted Source, in the form of Data. You can remove them, once pointed out.

Also, unused Code and Data may be compiled in the original PE, because the programmers do not always want to clean-up their Sources. There are several reasons for this. For example, once we have written a pretty Routine, that is useless, for the given Application, we might want to keep it there, just in case it could become useful later. Or more trivially, we simply wrote a useless Routine and forgot about it (and it is left over).

In that matter, the difference between your Sources and a Disassembly, is that the Disassembler may have simply failed to point out some relationship, say, from Data Pointers to code management, even if the rebuilt code seems to work fine. So, you have to make sure that all of the original PE functionalities are really fully assumed by the rebuilt code, before you go forward with deleting anything.

In a perfect rebuild, you will find many Data Labels that are of no or little use. For example evident valid Strings that are split into two parts, by the Disassembler output. This is normal, because the Disassembler’s choice is to output all possible Labels, even if useless, to keep free from missing Labels that would be real failure cases. Better too much than not enough. These can really be removed with few precautions.

Notice, also, that, for wrong rebuilds (rebuilds that are correctly re-compiled, but that do not correctly re-run), this Dialog can be detoured from its original purpose to point out where some Recognition(s) went wrong. For example, if a valid Code Label is shown unused, this offers the possibility to track down where it should have been evocated, and therefore, to point out what should be fed in the Interactive Dialog.

~~~~~~~