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

[Roland McGrath <roland at redhat dot com>]

Dan is right on the money, as usual.  As to why the entry point page was
added on x86, correct: int $0x80 is the traditional Linux/x86 system call
ABI and still works of course; newer x86 processors support "sysenter",
which enters kernel mode without saving state in a normal trap frame and
takes many fewer cycles than the normal trap path "int N" uses; AMD64
processors running 32-bit x86 code support "syscall", which is similarly
cheaper and more constrained on the kernel side than a vanilla trap.
(There is not at the moment a vsyscall DSO for native AMD64 processes.  I
may have said or implied there was, because that's what I'd been thinking.
In fact, there is a kernel entry page in a different form that probably
will need to be revamped into the same vsyscall DSO plan to support
unwinding properly.)  On the ia64 there is analogously a new and spiffier
way to enter the kernel than the old "break" instruction (the generic trap
requester instruction): it has a really cool feature, wherein there is an
extra kind of permission bit in the page tables that permits code on that
page to execute the magic "epc" instruction, which puts the processor in a
special semiprivileged mode without the overhead of a normal trap into
kernel mode, letting it access kernel memory and some other such things
that might suffice for a given system call's implementation (and then
return to normal user mode again) while never fully reloading some kinds of
internal state a normal trap would do.  I don't know enough about any other
processor off hand to speculate whether a similar new generic kernel-entry
mechanism might come in there.  But, as Dan has pointed out, there are
various system calls that can be optimized by implementing them in
kernel-supplied code that runs purely in user mode (such techniques are
well-travelled in research kernels); so it is reasonable to speculate that
such a DSO might one day be use on any given machine.

Dan is also correct in his identification of the portability issues.  The
auxv arrangement, including NT_AUXV and /proc/*/auxv, is common to almost
every ELF-based Unix-like platform; the stack layout (not the access methods
AFAIK) is part of every SVR4 ABI spec, though not strictly within the
purview of the ELF format spec itself.  (AFAIK only GNU/Hurd doesn't use
AT_*.  Though AFAIK only Linux 2.6 and Solaris support NT_AUXV and
/proc/*/auxv, I am not aware of any system providing a different interface
for getting that information; i.e. things support those or nothing.)
However, the AT_* values (except for AT_NULL==0) are neither standardized
nor de facto reliably the same across operating systems (they are part of
the SVR4 ABI spec for each processor I believe).  The values in
include/elf/common.h are copied from glibc's <elf.h>, and are what GNU/Linux
uses.  Some of the values used on Solaris conflict, though Sun seems to have
taken to using AT_SUN_* names and values >=2000 for recent additions and so
it now seems unlikely they will use values 32 or 33 and thus risk false
matches with the Linux AT_SYSINFO_EHDR tag.  (FYI, NetBSD's elf.h header has
all of Sun's values and no GNU/Linux values; however NetBSD itself uses only
the tags <10 which in fact match exactly everywhere.)

So the actual call checking for AT_SYSINFO_EHDR belongs in linux-tdep (and
added separately to other OS-tdep's if any other systems follow suit).  But
there's no reason the code that does the real work shouldn't be in shared
or generic ELF-specific places so that the OS-tdep portion is just a line
or two.  The add-symbol-file-from-memory command is the larger chunk of
that work.  Its extant implementation is ELF-specific, but the notion is
not; so, consistent with other gdb features, it would make sense for the
command to exist but fail with "not supported on this target" for non-ELF
targets.  Where the other part of the work (AT_SYSINFO_EHDR checking)
belongs we can pick up in the other thread, which is where this message
really belonged too.


Thanks,
Roland