Real multilib

[Warner Losh]

[[ Moved to arch@ ]]


> On Jan 11, 2016, at 9:14 PM, Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:
> 
> 
> 
> On 01/11/16 19:11, Warner Losh wrote:
>>> On Jan 11, 2016, at 3:16 PM, Brooks Davis <brooks at freebsd.org> wrote:
>>> 
>>> On Sun, Jan 03, 2016 at 06:41:33PM +0100, Dimitry Andric wrote:
>>>> On 03 Jan 2016, at 05:32, Warner Losh <imp at FreeBSD.org> wrote:
>>>>> Author: imp
>>>>> Date: Sun Jan  3 04:32:05 2016
>>>>> New Revision: 293068
>>>>> URL: https://svnweb.freebsd.org/changeset/base/293068
>>>>> 
>>>>> Log:
>>>>> Add libsoft to the tree, just like lib32.
>>>> Hmm, are there going to be more of these "multilib" things? :)
>>> We'll want to do something about supporting hard float on MIPS.  Over
>>> there it may be more of a TARGET_ARCH thing, but libsoft might be useful.
>> It isn’t quite a TARGET_ARCH on mips either. I’d love to work with you
>> to use this stuff  MIPS turns out to be a harder nut to crack with this stuff
>> because it marks the different types of binaries differently and it looks harder
>> to parse.
>> 
>> For amv6 it is more of a transition thing, but I wanted to do it something
>> approaching “correct” so that we could leverage it for MIPS.
>> 
>>> We've also got a libcheri in CheriBSD and will eventually need to do a
>>> lib64 as we explore the switch from CHERI-when-requested to
>>> CHERI-by-default.
>> We should definitely chat about this. There’s some easy ways to mark the CHERI
>> binaries that are easier than others which would be quite helpful.
>> 
>> So we should chat about how this would be helpful on MIPS, and not just
>> CHERI-mips...
>> 
>> Warner
>> 
> 
> For things that are a MACHINE_ARCH, do we want a convention of lib/${MACHINE_ARCH}? That seems like it would make it easily scalable and easier to predict than a lot of lib*. For things that aren't quite a MACHINE_ARCH, it's more complicated of course.

I’m not sure. If we were designing things from scratch, this might make some sense. Though
honestly, I’d make it be multilib/${MACHINE_ARCH} so that lib could be a symlink there so
that most config scripts that simply know where things live can find them more easily. Since
we have a big legacy issue to cope with, I’m having trouble seeing a clear path here. There
might be one, but I haven’t connected all the dots in my head…

Plus, MACHINE_ARCH likely isn’t expressive enough. The armv6 kernels, for example, can
run either soft-float ABI or hard-float ABI programs equally well (which is why my hack works).
It is my belief that, when booted on a hardware capable processor, a mips kernel could do the
same thing. There’s no floats passed into the kernel for system calls, so the floating point part
of the ABI in use is simply irrelevant.

I wonder if someone has a good write-up on how this stuff is normally done on, say, Linux. My
google searches have found lots of entries about how to enable it, but not what the underlying
scheme really is or good docs on the architecture. This is one of the things that stalled what I
did for so long. But after seeing Brooks' talk on libcheri, I thought I’d move forward with what I
have.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20160111/be31c66c/attachment.sig>