[Openmcl-devel] linux 2.6.23

[Gary Byers]

I was actually looking at this (a lot of what I've been knee-deep in
involves Linux.)

There are some fields in dynamic linker data structures that might
be absolute addresses or offsets from some base address.  There's
a comment in the function SONAME-PTR-FROM-LINK-MAP that says:

       ;;; Walk over the entries in the file's dynamic segment; the
       ;;; last such entry will have a tag of #$DT_NULL.  Note the
       ;;; (loaded,on Linux; relative to link_map.l_addr on FreeBSD)
       ;;; address of the dynamic string table and the offset of the
       ;;; #$DT_SONAME string in that string table.

Apparently, it's not just an OS convention that can be handled
at read time; sometimes (perhaps related to the vDSO getting loaded)
it's an offset on Linux as well, and we treat a negative offset
that looks like "#xffffffffffffnnnn" as if it were an absolute
address and wackiness ensues.

It'd probably work reasonably well to say "if that thing that could
be either an offset or an address is negative, it's an offset."  It'd
be even better if there was a bit somewhere that said how to interpret
it.

I think that vDSOs have been around for a while.  On PPC64 Linux,
part of a vDSO used to wind up at address 0 in 64-bit OpenMCL;
I think that that was a kernel/dynamic linker bug that's been fixed.
The new behavior seems to involve whether some "entries in a file's
dynamic segment" are relative or absolute when the vDSO is loaded,
and that may suggest that there's new code to load it (or that
they're new to x86-64 Linux.)

Thanks; should be fixed soon and glad that there seems to be a
workaround (vdso=0).


On Sat, 3 Nov 2007, Takehiko Abe wrote:

> Gary Byers wrote:
>
>> I'll try to install 2.6.23 on a laptop here when I get the chance.
>> if you haven't heard from me in a few days, please nag.
>
> Not to nag you -- you must be busy working on OSX -- just want
> to inform that I think I found a culprit.
>
> It's something called vDSO introduced into 2.6.23 kernel.
> I still don't know what it is. It has something to do with
> shared libs.
>
> Quote: http://lkml.org/lkml/2007/7/19/125
>
> | A vDSO is a ELF shared library supplied by the kernel that is mapped
> | into user address space.  The vDSO mapping is randomized for each
> | process for security reasons.
> |
> | [...]
> |
> | The vdso can be disabled with vdso=0
>
> And disabling it lets the Clozure CL run fine.
>
> btw, CCL dies (with vdso enabled) around %cstrcmp inside
> revive-shared-libraries because libname is not a correct
> cstring:
>
> (%walk-shared-libraries
> #'(lambda (m)
>     (with-macptrs (libname)
>       (%setf-macptr libname
> 		     (soname-ptr-from-link-map m))
>       (unless (%null-ptr-p libname)
> 	 (when (%cstrcmp soname libname)
> 	   (return-from found  m))))))
>
> I'll dig further on this weekend.
>
> Anyways, a simple workaround is to put 'vdso=0' to kernel boot option.
>
> Cheers,
> T.
>
>
>