From: John Gilmore <gnu@toad.com>
To: Martin Runge <martin.runge@web.de>
Cc: gdb@sourceware.org, Martin Runge <martin.runge@rohde-schwarz.com>
Subject: Re: RFC: include mod time and size in DWARF file name table
Date: Sun, 13 Jan 2013 04:19:00 -0000 [thread overview]
Message-ID: <201301130519.r0D5JQJJ016059@new.toad.com> (raw)
In-Reply-To: <CAF4KFGoTbn53j=jDgnddc1OmOvavUEN_=_sHkXOpOqf55F1O_Q@mail.gmail.com>
> Does anybody see any problems with this approach that I just havn't
> run into yet? And if it works, would the gdb developers support a
> change request to GCC/binutils?
Yes. The big problem with this approach is that you can never compile
the same source code files to produce the same binary code files.
In other words, it becomes hard to tell whether you actually have the
source code that matches your binaries -- because there will always be
diffs between the binaries you're investigating, and the binaries that
you just compiled from source. You start needing more and more
complicated "object file diff" tools, which can have their own obscure
failures because they aren't commonly used like "cmp" and "diff" are.
At Cygnus we weeded out all the ways in which dates, times, temporary
file names, hostnames, etc, were wending their way into object files.
We did that so we could make damn sure that the compiler was producing
the exact same object code when compiling on every host platform. So
that we could make sure that the 3-phase compiler bootstrap produced
the same object code when the compiler was compiled with itself, as
when the compiler was compiled with some other compiler. So that
we could verify that a Linux distribution that claims to ship "matching
source code" actually does ship the source code that matches all their
binaries. (So far I don't know of any distro that actually does
validate this -- so I suspect they are failing in a variety of ways.
What isn't regularly tested is probably broken.)
We found many, many bugs of all sorts by being able to do direct
binary comparison to detect allegedly "just the same" object files
that actually weren't the same. Uninitialized variables, alignment
issues, byte order problems, freeing of memory before using it, etc,
etc, etc, all turn up as minor, minor changes in the generated object
files. The minor loss of function such as not having GDB warn you
when you invoke the wrong symbol file, is well worth the price of
immediately and automatically detecting all those bugs.
John
next prev parent reply other threads:[~2013-01-13 4:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-12 13:24 Martin Runge
2013-01-13 4:19 ` John Gilmore [this message]
2013-01-13 5:54 ` Joel Brobecker
2013-01-14 12:31 ` Martin Runge
2013-01-15 17:51 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201301130519.r0D5JQJJ016059@new.toad.com \
--to=gnu@toad.com \
--cc=gdb@sourceware.org \
--cc=martin.runge@rohde-schwarz.com \
--cc=martin.runge@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox