On Wed, 21 Feb 2018, Benno Rice wrote:
On Feb 21, 2018, at 10:46 AM, Colin Percival <cperc...@tarsnap.com> wrote:
On 02/21/18 10:10, Benno Rice wrote:
Curiously, changing whitespace seems to cause the md5 of the .o files to differ
these days hence the following testing strategy:
Tested by: objdump -d | md5 (both in-tree clang and lang/gcc6)
objdump -d only dissassembles the text section (and does a bad job of that,
with calls to extern functions printed as
e8 fc ff ff ff call <garbage address>
on i386 (here 0xe8 is the opcode for the call instruction, and fc ff ff ff is
-4 which is a placeholder for the eventual offset, and <garbage address> is
the result of adding -4 to the current program counter. The symbol table
gives the name of linked address, but the garbage offset is used to form
the garbage address instead of printing this name.
So objdump -d would miss the large change of calling a different extern
Is this simply because line numbers are changing? That isn't new; I remember
a case where a security advisory touched a .h file and suddenly a huge number
of binaries changed because they included header file line numbers.
No, it happened when I changed the indent of the while statement on line ~132
in memcpy. I do suspect debug info though.
Isn't there a binary compiled without any debug info?
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"