[davidm@napali.hpl.hp.com: readelf question]

[Roland McGrath]

>   Andrew> Last I heard was a kernel patch to make auxv info available
>   Andrew> in the core file, and via the /proc and ptrace interfaces.
> 
> Yes: auxv, core, and ptrace are there.  I don't think /proc support is
> there.  Not sure if Roland is planning to do something about that.

To clarify, I think what David's saying (and what I think is the case) is
that access to these memory regions via core dumps and ptrace does work
just like any other user address, and that the startup-time aux vector on a
process's stack contains AT_SYSINFO_EHDR to tell the process the location.

The piece that still remains missing is gdb finding out where the DSO is,
i.e. the AT_SYSINFO_EHDR value of a traced process.  For that, I've
proposed a new /proc/PID/auxv virtual file and a new NT_AUXV note in core
dumps (these match exactly what Solaris provides).  I posted a patch to
implement this in Linux 2.5 to lkml on May 15; it was met with resounding
silence.  Pushing that patch has not been top priority since then, since
this issue affects gdb only with 2.5 kernels and so is not an imminent
concern for the Red Hat products I work on.  

After posting that patch, I realized it had a leak.  I didn't bother to
follow up with the corrected patch immediately, since my posting of the
first patch had failed to solicit any response of any kind even on the
question of the interface.  I would be happy to dust off that patch and
send it to you, post it again, or send it anywhere else that would increase
the likelihood of getting some response about it.  If Linux kernel folks
are happy enough with the interface but not with the implementation, I
would be glad to rewrite it as requested.  

>   Andrew> Thing is, if that's done, those extra memory sections can go
>   Andrew> back to being extra memory sections (and everything becomes
>   Andrew> much simpler).

I don't really understand what this comment means from its content.  The
special page(s) the kernel provides for the vsyscall/gate DSO are already
normal regions of memory as far as access via ptrace, /proc, and ocre dumps
is concerned.  I can guess from Andrew's past comments that he is in fact
talking about the auxv access feature, and trying to say that he believes
having that simplifies the interpretation of core files as opposed to using
the core files' new phdrs for that (something that is in fact trivial and
I've already implemented).  

In prior discussion, it was the clear conclusion that gdb hackers' highest
preference is for the /proc/PID/auxv+NT_AUXV kernel interface being added.
I have repeatedly made clear that I am happy to implement whatever
combination of things jibes best with the preferences of Linux kernel
hackers and gdb hackers.  So far we have no input whatosever on what the
preferences from the kernel side might be.

> I don't have much of a preference myself.  I'm sure Roland has thought
> much more about the user-level parts of the support than I have
> (though I do like the idea of being able to get symbol and library
> info for the kernel DSO(s); not sure how you'd do that with plain
> memory sections).

We have discussed it in great detail on the gdb list.
Check the archives.


Thanks,
Roland