Re: [PATCH] add-symbol-file-from-memory command

[Jim Blandy <jimb@redhat.com>]

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.

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

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