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

[John Gilmore <gnu@toad.com>]

> Interesting timing. I have just posted 
> http://sourceware.org/ml/gdb-patches/2012-12/msg00776.html addressing 
> this issue.

That's a useful patch.  It's smart to read the headers from the
"symbol_file" bfd (well, in this case the solib bfd used for symbols)
rather than from the "exec_file" bfd.

But doesn't it read the ELF header twice?  In
svr4_validate_hdrs_match, it reads it once in the call to
read_elf_header_from_target, and then reads it again by calling
read_program_headers_from_target which again calls
read_elf_header_from_target.  I suspect that you should pass the
already-read ELF header into each of the read_program_headers
functions.

Also, in read_elf_header_from_bfd, BFD has probably already read the
ELF header, when it first opened the file, and has it lying around.
This code should not be (1) reading it again, nor (2) seeking to file
offset "0" (not even a #define, not even "0L", but an int constant!)
to get it.

Also, it might be simpler in read_program_headers_from_target to just
translate the ELF header into its internal BFD struct form - then all
that manual messing with byte orders and field lengths could be
eliminated.  See how read_program_headers_from_bfd does it.

You could also just call bfd_get_elf_phdrs (and before that,
bfd_get_elf_phdr_upper_bound to size the buffer) which would avoid
spreading details into GDB about these headers and how they are read
and translated into local byte order.  BFD even has a
bfd_elf_bfd_from_remote_memory function for creating a BFD by portably
reading the target's ELF header and phdrs out of memory.

Also, is "validate" the right name for this?  That works for checking
shared libraries, but it's not as obvious what this function should
do when e.g. checking the argument to symbol_file, or immediately
after doing "target attach remote".  If "validation" fails, should
we refuse to read that symbol file, or refuse to attach to the remote
target?  What exactly are we validating?  Perhaps "compare_headers"
or "do_symbols_and_target_match" are better names.

With those things addressed, it's a good start.  Then, shouldn't this
call be implemented for non-shared-library symbol files (like
Mr. Zulliger was hoping for), and for object file formats other than
ELF?

Has this code been tested when the target uses a different byte
order than the host?  Probably not, since it is only currently invoked
for shared library loads, which usually only happen native.  Is
there a test case written for it?

Could it be easily extended to check a build-id when one exists?  Or
would that require different function arguments, or need to happen at
a different time?

Should "target attach" do this kind of validation traffic to and from
the target?  Or should checking this be a separate step initiated by
the user?  The target might be in a relatively sensitive state -- or
the user might not want to wait for this check -- immediately after
attaching.  We could add yet another GDB setting for automatic or
manual validation, defaulting to "check", and requiring those who want
to bypass the check to set that setting.  Is that too much
complication for the gain?

	John