Re: unwind support for Linux 2.6 vsyscall DSO

[Elena Zannoni <ezannoni@redhat.com>]

Roland McGrath writes:
 > In the past (during this spring and summer) there were some discussions
 > about the need to find unwind info in the vsyscall DSO image implicitly
 > loaded in processes on Linux 2.5/2.6 on some platforms.  I honestly don't
 > recall which mailing lists this was on.  If people are not clear on the
 > issues, I can try to dig up the various summaries of the details I have
 > posted before.  This was tabled for a while when I had other priorities
 > since it didn't turn out to be an issue with any kernel version used by
 > Red Hat production systems.
 > 
 > Now Linux 2.6 is getting firmed up, and it's time to revisit this.  On
 > Linux 2.6 kernels, backtraces from programs stopped in system calls do not
 > work using current glibc on x86 and AMD64 machines.  The same issue exists
 > on IA64 in Linux 2.6, and glibc will before long make use of the feature so
 > that system call backtraces need the same solutions for IA64.
 > 
 > My changes to export the auxv information in core dumps and /proc are now
 > making their way into Linux 2.6, and this gives us the tools we need to
 > solve the problem in gdb.

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.

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. Have a look at target_find_memory_regions. It is defined for
linux in linux-proc.c, and for Solaris in procfs.c, and for fbsd as
well. It is just an iterator over the entries in the map file, but you
get the general idea. There is a bug in there as it is not defined
properly for the core target, while in this case it obviously should
be. This way it could be easily extended for Solaris, etc too, some
day.

For the core file case, look at
gcore.c:objfile_find_memory_regions(). This is the one that fiddles
with remote/core cases. You are in an analogous situation here with
reading from bfd instead of /proc.

Of course, the target_find_memory_regions() function is called only by
the gcore command, which is quite different from what you need to do.

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. I have some solib debug code that
Kevin approved for mainline, I'll commit it now, if that can be of
help in seeing what happens when shlibs are loaded.

elena