[PATCH] add-symbol-file-from-memory command
Michael Snyder
msnyder@redhat.com
Tue Oct 7 23:32:00 GMT 2003
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?
More information about the Gdb-patches
mailing list