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

[Daniel Jacobowitz <drow at mvista dot com>]

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer