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

[Aleksandar Ristovski <aristovski@qnx.com>]

On 12-12-25 08:35 PM, John Gilmore wrote:
>> 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

Thank you for your comments. I will try to address your concerns and 
come up with a better patch. Due to other priorities, it will most 
probably not be before another few weeks.

---
Aleksandar