On Mon, Oct 06, 2003 at 10:29:05AM -0500, Jim Blandy wrote:
It seems I'm confused about where the vsyscall support is useful. I
thought it was Linux-specific, but folks disagreed. I think it's
important to get this right, because that determines where the code
goes in GDB and what the interfaces are.
No, I agree with you that vsyscalls are Linux-specific - for now at
least. But I think that the concept of add-symbol-file-from-memory is
well separated from the concept of vsyscalls. It seems like a useful
thing to have for interacting with, say, a hypothetical minimalist ELF
shared loader.
(This message rambles in a whiney sort of way, and then asks specific
questions at bottom.)
One of the sources of my confusion is whether it's Linux-specific or
ELF-specific. The vsyscall DSO only appears on Linux --- at the
moment. But supporting it in GDB can be done without reference to
anything Linux-specific: you need to check the auxilliary vector (an
ELF thing) and read an ELF file out of memory. It never makes
Linux-specific system calls, or relies on Linux-specific filesystem
layout stuff, for example. So leaving linux-tdep.c and
config/nm-linux.h out of the picture entirely, and doing everything as
ELF-related code, will not introduce any interface violations.
Except that the AT_SYSINFO tag is really Linux-specific. There's no
guarantee that nothing else would use the same auxv tag for something
else. I don't believe they're centrally registered, since they're
ultimately system-specific by nature.
But although I understand that the Linux system call interface is
changing, and that the new interface requires the kernel to provide
unwinding information, because the old way of unwinding from system
calls no longer works, I've never understood why the system call
interface had to change in the first place.
In a sense, it's irrelevant --- the interface *is* changing, and GDB
must continue to work. But not understanding why the system call
interface must change makes it difficult for me to assess how likely
other systems are to adopt vsyscall DSO's, and thus whether it's
better to isolate the additional complexity to Linux-specific files,
even though the work is portable to all ELF targets, or whether it's
better to make it ELF-specific, to make it easy (or unnecessary) to
adapt GDB when the feature appears elsewhere.
I think there's a good argument that one should simply always
implement everything using the smallest interface you can stand, even
if it's only used in a specific situation, because it makes the code
easier to reuse. Since the vsyscall DSO support only really depends
on ELF stuff, and it automatically detects when it's needed (by the
presence of a specific element in the auxilliary vector), maybe that's
the best thing to do.
So, why did the kernel system call interface need to change? How
likely are other Unices to begin using vsyscall DSO's? I've seen
x86-64 and IA-64 mentioned; would it be useful on PPC and the S/390,
too? (Just to pick random architectures out of the air.)
This is all "as I understand it". Feel free to correct, anyone.
The original motivation for x86 was that we have three different
mechanisms for making a syscall:
- int $80
- sysenter
- syscall
It turns out that int $80 isn't the best way any more, on some
processors. sysenter (?) is much faster. But changing the syscall
interface is something that has to be done very delicately.... so the
"new" way of doing syscalls isn't using sysenter, which wouldn't work
everywhere etc. It's "jump to this address in a preloaded DSO, on a
kernel-mapped high memory page". It's simple, powerful, extensible.
The kernel can do other neat things with it too. For ia64 there's been
discussion of lightweight syscalls which can be implemented entirely
within that page. Gettimeofday is the best example. I think there are
some synchronization etc. issues with this (plus you lose strace
ability if you're not careful!) so it hasn't been done yet.
And this page can also be used for signal trampolines, and is on some
architectures. Which is a beauteous and wonderful thing, because it
can provide DWARF-2 CFI information for the signal trampoline.
I suspect at least the signal trampolines and lightweight syscalls
could be useful on other architectures also.