Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath <roland at redhat dot com>]

> Ok, reading the thread, I see that you are running pretty much into
> the same problems I am running into for PIE support.  What kind of
> information is exacty exported into the auxv file?  I am wondering if
> you also have the entry point of the program there (AT_ENTRY, looking
> at the Solaris auxv.h), because if so it may change my current way of
> looking at PIE, where I am taking the info from the /proc/pid/map
> file, which is not saved in the core file, I think, while auxv is.

Try "LD_SHOW_AUXV=1 /bin/true" (i.e. put that in the environment of any
program--it's checked by the dynamic linker).  That shows you all the
information that the kernel supplies in this fashion (you have to be using
Linux 2.6 to see AT_SYSINFO and AT_SYSINFO_EHDR in there).  AT_ENTRY is
certainly there--that's how the dynamic linker knows where to jump to start
the program after initialization.  There is also AT_PHDR, which is another
thing that gives you the runtime address of something that you know the
link-time address of (PT_PHDR).  If access to AT_ENTRY alone doesn't solve
your problem with PIE, I'd like to help figure out what else it is you
need; so please raise that in a separate thread CC'd to me.

> Anyway, this issue aside, there is a target method in gdb to process the
> various entries in the map file. I think it would be appropriate to
> translate that into something similar for reading the auxv file.

Ok.  This is what Jim suggested too.  Do you have a function signature in mind?
Perhaps:

  int (*to_get_auxv_data) (char **data, size_t *size);

that fills in a malloc'd block.  (The data will be examined briefly and
thrown away, but malloc seems like the simplest clean interface to use.)

> I agree that treating this new information as much as possible as a
> shared library will make our life easier, because all the checks are
> done in the right spots already. 

and Jim wrote:

> I think you can rely on SOLIB_ADD not being called too early.  It would
> be a bug if we ever called it before the shell execs the executable under
> debug, because we use the VMA of the .dynamic section of the executable
> file to find the dynamic structure in the inferior's memory anyway.  We
> couldn't even find the shell's shared library list.

Right, it would fail to find any list at all.  If it treats that as "empty
list" then this won't be a change from before and so it's a harmless no-op.
Are we sure that is not what is happening now?  If it is, it's harmless now
but having the auxv-reading done too early would not be harmless.

> I disagree with moving the read of auxv to bfd. Gdb already processes
> plenty of /proc files (on Solaris using 2 interfaces), and has target
> methods defined for these, so I would treat the auxv case just like the
> others.

What we have been discussing most recently is only a BFD utility function
to examine raw auxv blocks that have already been read in somehow.
i.e., a trivial helper function that these target methods would use.
It doesn't matter to me whether this is in bfd/elf.c or gdb/elfread.c.



Thanks,
Roland