オブジェクト生成物の確認方法とは

デコンパイル…初めて聞きました。
世の中にはそういった手法もあるのですね。
ツールやソフトを使ったことがありません；
メモリから無理やり書き起こしたコードを用いて適正か評価するとは凄いですね。
調べてみましたが、なにが正しそうか読み取るのが逆に難しそうです。

そもそもコンパイラを詳しく理解していないため、時間を要しそうです。
ご回答ありがとうございました。
（以下は参考に読んでみました。リンクべた貼りで申し訳ないです。
・https://rightcode.co.jp/blog/information-technology/c-language-gdb-decompile-vernam-cipher-decryption
・https://corgi-lab.com/programming/c-lang/reverse-assemble/
・http://www5d.biglobe.ne.jp/~noocyte/Programming/Decompile.html#CDecompilerPossiblity）

なにが正しそうか読み取る

細かい読取はしません。バイナリの比較で差分があっても、同じ環境でデコンパイルしたソース同士の比較一致をみれば明白と判断。

無理やり書き起こしたコード

コンパイルの逆をやっているだけなので変数名とかは適当になりますが、
バイナリを見るより人間的です。
各CPU向けのコンパイラに対する学習コストも不要です。
ただ、商用商品にかけるとリバースエンジニアリングになるのでご注意ください。

まさに、参考記事に上げていただいた記事を拝読しました。
＞差分が出た場合、バイナリ比較をしてみると勉強になると思います。
ご教授ありがとうございます。バイナリ比較で差分が生じた場合の具体例は環境によるので、どこかに載っているわけではなさそうですね。
makeの命令を根気強く追いかけたり、コンパイラの環境を比較したりして整えるほどしか言いようがないのかもしれません。

特に身の回りでも、以下の部分が議論されます。（記事から引用）
　＞1.ビルド環境 (OS や Visual Studio など) の移行を行うので、移行前後の成果物を比較してビルド環境に問題がないことを保証したい
　＞2. ビルド毎に得られる成果物をバイナリ比較することでそれらが同等であるかを確認し、再テストや再リリースの要否を判断したい

記事の中では以下のように前置きの結論がある上で、「ソースコードやリンクされるオブジェクト類が同一であれば、同じビルド ツールによって生成されるビルド成果物の動作や機能に相違が生じるようなことは通常ありません。」と括られていました。（記事を要約）
　1.ビルド成果物は同一にならない可能性がある。
　　同一になったとしてもビルド環境に問題がないことの保証にもならない。
　2.同一のビルド成果物を得るための環境や、前提条件と、ビルド成果物に相違が生じる要因やビルドツールの対応状況について理解することが重要。

＞ただ実開発において、バイナリが変わらないような微修正って、そんなに多くないと思います。
コードを整える程度の微修正を行った場合を想定していました。
ご回答ありがとうございました。

＞商業でいちいちバイナリの比較なんてする人いないと思います.
＞コンパイラっていうのはほんっっっとに低レイヤー向けにソースを変換する以上そんなもんの評価は現実的に不可能なので,世の人はふつうテストを書きます.
ご回答ありがとうございました。
バイナリ比較といった言葉をたびたび耳にしていたため、商業で比較することない、ふつうはテストといったご意見に目から鱗でした。
言語がCのため、低レイヤに位置しているといえるかもしれません。
私自身は技術力がかなり疎く、テストするにも何事にも時間を何倍もかけてしまうので、効率的な評価方法を探しておりました。

＞コンパイラの生成物にはタイムスタンプやソースのファイルパスが含まれることがあり、入力が同じでも生成物が一致しないことは往々にしてあります。
そのようです。

ご紹介いただいたブログ読みましたが、今の私には難しく厳しい内容でした。
せっかくいただいたのに申し訳ありません。
ひとまず、「reproducible builds あるいは deterministic builds」といい、
和訳分では、決定的ビルド、再現可能ビルド、密閉ビルド、と表現できるのですね。
リファレンスのご紹介もありがとうございました。
コンパイラについて強くならないといけないかもしれません。
ご回答ありがとうございました。