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

[Michael Snyder <msnyder@redhat.com>]

Daniel Jacobowitz wrote:
> 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.
> 

So, coming late to the discussion, is it fair to summarize that
a consensus is emerging that this is good and needful functionality,
which should go into gdb, pending only the resolution of a few
naming and placement issues?