Re: Ensure correct symbol-file when attaching to a (remote) process

[John Gilmore <gnu at toad dot com>]

> > Is there really no such mechanism in GDB?
> 
> There is no such reliable mechanism in general.

If gdb had a local copy of the binary object file (not just the
symbols), it could try to read arbitrary locations in that file, and
read the same locations in the remote target, and compare the two.
(This would take a bit of work, since it would have to manually walk
the target stack to find and access the local object file.)

Only if you read back every byte of the object file could you be SURE
that the remote target contained the same thing.  In that case you
might as well have just written the entire object file TO the target.
Either would be extremely slow.

Testing just a few places in memory is unlikely to detect the kinds of
small changes that debugging cycles frequently make to programs.  This
is why gdb doesn't do it by default (I considered it when making the
target stack first work).  If someone wrote such a command as a GDB
enhancement, and submitted the patch, it could probably be added as a
specific command ("verify-target percent" where percent is what
fraction of the address space to compare -- default should probably be
super quick, 0.00001% or something).

You'd also have to make a decision about what to do with data areas
and bss (zeroed) areas.  In a remote target, after the program has
been run one or more times, these will normally be overwritten with
updated variable values.  When restarting the program, there is no
guarantee that the program's initialization code will restore them,
nor that the rest of the program's code won't depend on the initial
values in these variables.  When merely connecting GDB to debug an
already-running target in mid-execution, these variables can have any
values.  The best you can do in an automated way is to check the areas
of memory that are intended to contain instructions and read-only
data.  (And in some targets, such as the Linux kernel, even that check
will fail, since it links initialization code separately from running
code, and overwrites the initialization code with data areas after it
has initialized the kernel.)

	John