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

[Andrew Cagney <ac131313@redhat.com>]

> On Tue, 17 Jun 2003 15:26:35 -0400, Andrew Cagney <ac131313@redhat.com> said:
> 
> 
>   Andrew> David, I'm guessing that ``gate page'' is vsyscall page?
> 
> Yes.  To be precise: on ia64, the gate page serves a similar purpose
> as on x86 the vsyscall page.  (ia64 linux doesn't actually support
> virtual syscalls; instead, there are lightweight syscalls, which have
> similar performance but aren't restricted to user-mode execution).
> 
>   Andrew> Whats the Linux kernel status on this one?
> 
> They're in the 2.5 tree now (both on x86 and ia64).

Ya!  Signs of sanity!  Shame no one thought to mention that here :-(

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

I think it was in the patch?

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

The discussion is in the archives.

The auxv provides the address of the start of vsyscall page.  GDB can 
then use that to fudge up a bfd describing those memory contents.  This 
has several important properties:

- GDB always uses the AUXV address.  That way GDB uses a single 
consistent and robust mechanism on both core files and live processes.

- GDB needs the AUXV anyway.  With out it, GDB would be forced to rely 
on heuristics when trying to determine the address of the vsyscall page 
in an already running process (it can't trust the stack).

So, while at first sight, having the core headers describe the syscall 
page symbol tables appears useful, it turns out to be less so.  Should 
it be pulled?

Andrew