Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath <roland at redhat dot com>]

> If the AT_ENTRY value is correct for PIE, gdb will need it.

Yes, it's correct in all cases.  You can be sure of this because it's the
only way the user entry point gets run by the dynamic linker, so if it were
wrong, the programs wouldn't run.

> You maybe are thinking that the tag is a parameter? If so the
> return value will need to differ depending on what you are looking
> for, and you will need a void* parameter (yuck!).

I don't know what you are talking about here.  bfd_vma is the only
appropriate type for all of the values in question.

> As I understood it, you will have a to_get_entry_point() and a
> to_get_vsyscall_entry(), which then will query the target (via
> to_query) for the auxv vector blocks and "parse" that.

I have never suggested to_get_vsyscall_entry and don't anticipate wanting
it.  I proposed to_read_aux_vector, and we have been discussing using
to_query to serve the same purpose with a different calling convention.
For the vsyscall purpose, I don't think any other target_ops addition is
useful or desireable.  The code to check for AT_SYSINFO_EHDR will be in the
linux-tdep function used for SOLIB_ADD or something like that (still being
hashed out, but that seems like the place for it).

to_get_entry_point seems like it might be a reasonable generic addition
since it's a generic issue that could apply to any kind of executable and
target in theory.  However, it might be desireable to frame it in terms of
a standard to_query request just so that remote.c and all the other target
code need not be touched, only the backends that can use the auxv fetching
and remote stubs that have a way to produce an answer.  There is the
contrary example of to_find_memory_regions, but that is notably wholly
unsupported by the remote protocol (i.e. no stub has the option of
implementing it even if it knows how).  The choice here is an issue for gdb
hackers, that I don't have any feelings about myself (just these observations).