Re: time to workaround libc/13097 in fsf gdb?

[Pedro Alves <palves at redhat dot com>]

On 09/12/2014 01:33 PM, Jan Kratochvil wrote:
> On Fri, 12 Sep 2014 14:14:36 +0200, Pedro Alves wrote:
>> I was more inclined to leave the vdso in the shared library list
>> though, like ldd does, than filtering it out.  Like, similar to
>> your gdbarch_solib_file_not_found_is_ok patch, but look at the
>> addresses rather than filenames in the hook.  I'm not sure
>> whether that'd complicate things too much.
> 
> Everything can be done but this is again changing a direction/behavior of GDB
> upon receiving a fix of current behavior.  So far GDB has not been including
> vDSO in the library list and the patch was fixing that behavior.  One can go
> very far from doing one fix up to rewriting GDB from scratch.

I think that's a bit uncalled for and unfair -- AIUI, your original patch
even did that; it left vdso.so in the list.

I had said:

 "Alternatively to hard coding the names, maybe we could match the vdso address
  found through that with the addresses found iterating the dynamic linker list, to
  know which dynamic linker entry is the vdso."

And your new patch said:

 "But now it discards any shared libraries which match a symbol file loaded via
  add-symbol-file-from-memory.  Which may be OK but it is more widespread change
  than before."

I was only clarifying what I had already said in the message
you replied to.  I have no idea what problems you found in
the original patch that led to redesigning the patch to filter
out instead, or what you saw that would suggest that doing that
change would require tilting so much in the "rewriting GDB from
scratch" direction.

Thanks,
Pedro Alves