Re: unwind support for Linux 2.6 vsyscall DSO

[Elena Zannoni <ezannoni at redhat dot com>]

Roland McGrath writes:
 > > 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.
 > 

ok.

 > > 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.)
 > 

There should be an iterator over the entries in the /proc/pid/auxv
file with a callback that processes each entry. So that the iterator
could be used not just for finding the AT_SYSINFO_EHDR entry. I think
the number of iterations would be your size_t above divided by the
size of an auxv_t or something similar.

For instance something like the one for solaris:

 * Call a callback function once for each mapping, passing it the mapping,
 * an optional secondary callback function, and some optional opaque data.
 * Quit and return the first non-zero value returned from the callback.
 *
 * Arguments:
 *   pi   -- procinfo struct for the process to be mapped.
 *   func -- callback function to be called by this iterator.
 *   data -- optional opaque data to be passed to the callback function.
 *   child_func -- optional secondary function pointer to be passed
 *                 to the child function.
 *
 * Return: First non-zero return value from the callback function, 
 *         or zero.
int
iterate_over_mappings (procinfo *pi, int (*child_func) (), void *data, 
		       int (*func) (struct prmap *map, 
				    int (*child_func) (), 
				    void *data))

In this case, instead of a prmap structure we would have an auxv_t
structure, or something like that. Doesn't need to be that complicated
as the one above. The linux one for reading MAP is a bit simpler.


 > > 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.
 > 

The first thing that happens is that the breakpoint inserted at the
dynamic linker is hit, at which point gdb gets to add the shlibs.
For instance with the debug output enabled:

[...start up gdb...]
(gdb) set debug solib 1
(gdb) b main
Breakpoint 1 at 0x80484ce: file /scratch/ezannoni/pie-work/src/gdb/testsuite/gdb.base/break.c, line 75.
(gdb) r
Starting program: /scratch/ezannoni/pie-work/native/gdb/testsuite/gdb.base/break 
enable_break: search for .interp in /scratch/ezannoni/pie-work/native/gdb/testsuite/gdb.base/break
enable_break: opening /lib/ld-linux.so.2
elf_locate_base: DT_DEBUG entry has value 0x0
svr4_current_sos: no DT_DEBUG found
enable_break: solib bp set
<<<<<<<<SOLIB BP HIT>>>>>>>>
elf_locate_base: DT_DEBUG entry has value 0x400136bc
svr4_current_sos: Processing DSO: /lib/i686/libm.so.6
svr4_current_sos: Processing DSO: /lib/i686/libc.so.6
svr4_current_sos: Processing DSO: /lib/ld-linux.so.2
svr4_current_sos: Processing DSO: /lib/i686/libm.so.6
svr4_current_sos: Processing DSO: /lib/i686/libc.so.6
svr4_current_sos: Processing DSO: /lib/ld-linux.so.2
svr4_current_sos: Processing DSO: /lib/i686/libm.so.6
svr4_current_sos: Processing DSO: /lib/i686/libc.so.6
svr4_current_sos: Processing DSO: /lib/ld-linux.so.2

I think we are safe here.

 > > 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.
 > 
 > 

Since we need the iterator method, this read/parse becomes a very
small piece and fits nicely in linux-proc.c in the live inferior
case. For the corefile/remote case, you would ask bfd for the .auxv
section of the core file and parse that in order to get an element of
the vector and this is also something that can be in gdb, unless you
want to reuse that in some other tool.

elena


 > 
 > Thanks,
 > Roland