On Mon, 2013-11-11 at 23:31 +0100, Robert Millan wrote: > On 11/11/2013 15:32, Mark Wielaard wrote: > > On Sun, 2013-11-10 at 00:45 +0100, Robert Millan wrote: > >> Nothing as far as ELF compliance is concerned. This tag is ment to be > >> consumed by the kernel ELF loader only. > > > > For elfutils elflint it also matters for things like STB_GNU_UNIQUE and > > STT_GNU_IFUNC. Does ELFOSABI_FREEBSD indicate the binaray can or cannot > > contain such symbol types or bindings? > > No, it just gives information about the kernel<->user ABI. > > AFAIK STB_GNU_UNIQUE and STT_GNU_IFUNC are userland facilities. Is this > correct?
It tells the shared library loader, ld.so, about the features of the ELF file, so it can resolve symbols with those bindings and/or types. > > elflint assumes those only occur > > with ELFOSABI_LINUX currently. > > Well I suppose you could extend this assumption to cover > ELFOSABI_FREEBSD as well? > > Though presence of ELFOSABI_FREEBSD is not enough to determine that they > are available. Indeed. Normally for the GNU toolchain, ELFOSABI_NONE describes "generic" ELF files, which don't use GNU extensions like STB_GNU_UNIQUE and STT_GNU_IFUNC. And ELFOSABI_LINUX describe ELF files which do use such GNU extensions. What is the convention on Debian/kfreebsd? > > /proc/PID/maps, /proc/PID/exe, /proc/PID/mem, > > Mostly OK I think. > > > /proc/TID/status > > It seems we don't have this. At least not in 9.0. :-( This one is mostly just used as a workaround to see whether ptrace correctly propagates a SIGSTOP on attach/detach. It can probably be ignored if ptrace "behaves". > > and /proc/PID/auvx > > Neither... That was a type BTW. Should have been auxv. It is sometimes possible to get at the AUXV information in a different way. If not available only some functionality is degraded. > > And /proc/kallsyms and /proc/modules are used to inspect kernel modules > > with libdwfl. > > Nope. For module listing we have kldstat() / kldfind() / kldnext(). > > > See libdwfl/linux-proc-maps.c (backend for dwfl_linux_proc_report) > > and libdwfl/linux-kernel-modules.c (backend for > > dwfl_linux_kernel_report_kernel and dwfl_linux_kernel_report_modules). > > Someone might want to provide > > backends for kfreebsd if the corresponding libdwfl dwfl_linux_* > functionality is wanted there. The kernel parts probably won't easily > work, the user > > space parts probably will assuming the /proc interface is linprocfs style > > and sufficiently compatible. > > Is it possible to disable this functionality on kFreeBSD? A quick > linprocfs solution seems like dead-end, and we really don't have the > manpower to write new backends from scratch. Well, it doesn't do much harm. It just means you cannot easily introspect the kernel and kernel modules with elfutils/libdwfl. But that is not functionality many programs want/need anyway. If they do, then there are probably other issues they have to deal with that make them depend on the linux kernel anyway. Cheers, Mark -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
