[Please remember that I am not on the mailing list, so make sure any
replies are also addressed to me directly.]

This patch against 2.5.68 turns the i386 vsyscall page into an ELF DSO, as
we discussed earlier.  I usurped the AT_SYSINFO_EH_FRAME number and
replaced it with AT_SYSINFO_EHDR, which points at the beginning of the page
where the DSO's ELF header is found.  Though AT_SYSINFO is left in for
compatibility, it is now superfluous since the vsyscall entry point can be
got from the e_entry field via AT_SYSINFO_EHDR with no additional overhead.

Two DSOs are built (a int $0x80 one and a sysenter one), using normal
assembly code and ld -shared with a special linker script.  Both images
(stripped ELF .so files) are embedded in __initdata space; sysenter_setup
copies one or the other whole image into the vsyscall page.  Each image is
a little under 2k (1884 and 1924) now, and could be trimmed a little bit
with some specialized ELF stripping that ld and strip don't do.  Adding
additional entry points should not have much additional overhead beyond the
code itself and the string size of new symbol names.

The code in the page is identical and still packed the same, but now at
0xffffe400.  The initializers for the page's contents are replaced with
assembly written like normal user-mode code, which is much easier to
maintain.  (Special care must still be taken by hand to make sure that the
entry points in both DSOs match up.)  Using a little additional ld
trickery, hand-written address constants for locations in the vsyscall page
are replaced with symbols that resolve the same at link-time but never need
hand-tweaking to match future changes to the vsyscall page code.  The
address 0xffffe000 is hard-wired in one place in the linker script used to
create the DSOs, and only there.

This patch also changes i386 core dumps to include the vsyscall DSO image
in the dump.  I believe this is important to do so that port-mortem
analysis of a core dump from a process that might have used PCs in the
vsyscall page does not depend on having the live kernel and hardware at the
time of analysis match the vsyscall page contents of the kernel that wrote
the core dump.  As well as dumping the memory, it copies other phdrs from
the DSO into the core file.  This is important to get the PT_GNU_EH_FRAME
information into the dump, where it serves the same purpose for post-mortem
analysis by the debugger that it serves in the live vsyscall DSO image for
cancelation handling.

I have tested the vsyscall DSO image with libc changes that use it (as well
as existing libc that needs AT_SYSINFO to work as it has before).
I have tested that core dumps are valid ELF and the new segments look correct.

Nothing yet in use needs the DSO to have symbol names, or an ELF soname, or
ELF symbol versions.  The selection of soname (in Makefile) and symbol
versions (in vsyscall.lds) are arbitrary and shouldn't be considered final
without some more thought.  Those can be changed or removed without
affecting anything in the kernel.  The exported symbol names __kernel_* are
also used inside the kernel now, but labels can be made in vsyscall-*.S for
kernel use irrespective of what names are chosen to export in the DSO
symbol table.

Please let me know if you like this or don't.


Thanks,
Roland