Re: Bug#649038: elfutils FTBFS on kfreebsd
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
Reply to: