0

I have a 20+ yo .dll, written in C that none of my colleagues want to touch. With good reason, it uses macros, macro constants and casting EVERYWHERE, making the symbol table quite lean.

Unfortunately, I have to sometimes debug this code and it drives me crazy that it doesn't use something as simple as enums which would put symbols in the .pdb file to make debugging just that little bit easier.

I would love to convert some of the #defines to enums, even if I don't change the variable types as yet, but there is a genuine fear that it will cause possible issues in terms of performance if it were to change the code generated.

I need to show definitively, that no compiled code changes will occur, but it would seem that the .dll is actually changing significantly in a 64 bit build. I looked at one of the function's disassembly code and it appears to be unaffected, but I need to show what is and is not changing in the binary to alleviate the fears of my colleagues as well as some of my own trepidation, plus the bewilderment as to why any changes would propagate to the .dll at all, though the .dlls are of the same size.

Does anyone have any idea how I could do this? I've tried to use dumpbin, but I'm not that familiar with it and am getting some mixed results, prolly because I'm not understanding the output as much as I like.

Adrian
  • 10,246
  • 4
  • 44
  • 110

1 Answers1

0

The way I did this was as follows:

  1. Turn on /FAs switch for project.
  2. Compile that project.
  3. Move the object file directory (Release => Release-without-enums)
  4. Change #defines to enums
  5. Compile that project again.
  6. Move the object file directory (Release => Release-with-enums)
  7. From a bash command line. Use the command from the parent of the Release directory:
for a in Release-without-enum/*.asm; do
    git diff --no-index --word-diff --color -U10000 $a "Release-with-enum/$(basename $a)";
done | less -R

The -U10000 is just so that I can see the entire file of each file. Remove it if you just want to see the changes.

This will list all of the modifications in the generated assembly code.

The changes found were as follows:

  1. Symbol addresses were moved about for apparently no reason
  2. Referencing __FILE__ seems to result in not getting a full path when using enums. Why this would translate to removing the full path when using enums is a mystery as the compiler flags have not changed.
  3. Some symbols were renamed for apparently no reason.

Edit

2 and 3 seem to be caused by a corrupted .pdb error. This might be due to the files being used in multiple projects in the same solution. Rebuilding the entire solution fixed those 2 problems.

Adrian
  • 10,246
  • 4
  • 44
  • 110