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

[John Gilmore <gnu at toad dot com>]

> I have addressed some of your concerns, and some issues I found while 
> writing the testcase. Please take a look: 
> http://sourceware.org/ml/gdb-patches/2012-12/msg00809.html

Thank you!

There are several places where you assume that there are only
two possible pointer sizes ("if (ptr_size == 4)" and "else").
These should abort -- or return false -- if they encounter a
pointer size they don't understand.  And what is this constant "4"
doing in there?

In read_program_headers_from_target, you initialize load_base_trusted
to 0, then in the first executable statement, you test it and abort if
it's zero.  It took me some detailed reading to discover that in
another initializer, you pass load_base_trusted's address to
lm_addr_check, which modifies it as a side effect.  Could you move that
call to lm_addr_check to just before the if statement, so it's clearly
in a place where people can see that a side effect will occur?

In svr4_validate_ehdr_match, you compare the "magic numbers" by
directly feeding struct pointers to memcmp.  You should compare
the magic number field the same way you compare all the other
fields -- as e.g. ehdr1->_32.e_magic.

I'm still bothered that you read the symbol file's ELF header three
times, once when BFD opens the file, once when you read the ELF header
because you don't use BFD's copy, and once again when you need it to
find the phdrs.  And you're still reading it from location "0" in the
file.  Ditto for accessing the target memory twice, unnecessarily.

I am also wondering why all this infrastructure has been made specific
to shared libraries (it's in the solib ops vector).  The original
request on the mailing list was for this validation to occur for
ordinary symbol-files; this implementation prevents it from ever
being used for that.

	John