This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]