Date: Mon, 11 Jan 2016 21:27:14 -0700 From: Warner Losh <imp@bsdimp.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: "freebsd-arch@freebsd.org" <arch@FreeBSD.org> Subject: Real multilib Message-ID: <AF46E4D8-EA45-4597-926A-E333A8473A15@bsdimp.com> In-Reply-To: <56947DAD.80106@freebsd.org> References: <201601030432.u034W6en043633@repo.freebsd.org> <D06026D1-5F5E-4D8A-8882-063BBFBF2903@FreeBSD.org> <20160111221614.GC79262@spindle.one-eyed-alien.net> <F67B40B5-6154-4098-93ED-EFEE6110FFF0@bsdimp.com> <56947DAD.80106@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] [[ Moved to arch@ ]] > On Jan 11, 2016, at 9:14 PM, Nathan Whitehorn <nwhitehorn@freebsd.org> wrote: > > > > On 01/11/16 19:11, Warner Losh wrote: >>> On Jan 11, 2016, at 3:16 PM, Brooks Davis <brooks@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@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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWlICiAAoJEGwc0Sh9sBEAXnwP/0Cnzc6m1X0TchlMDNN9fCv9 mk6Rs0z9IZdME76MLb/snqVDSLgPAOBPfblAPC180wJlj4bBvhtPWHv/2NEt+L5d PrhdIJP+MbJGqdJvh6HN34gwfUO9VAppXA48OOykvPVUAqRz+nBhhPhpfqWrbQhR fhQvcIY9+/z10urK7cSFODKuRxzfrSxKau+RYruT3lALkI+xGCd7Pc8wFd0g5Gb+ SS6KdKOjA3f8e5WpywJGYyNLEzofBYqhu8l6hUaTw+s1heV3aroq5TpZ213cKV2F iBmVYBnT72zmhovnoZVJCn+dJlNAahJ4p35yDuCKoxg37Jzxvb4bAbJOA+2fEvrv grkqwNZPvvNmiWdaNjiUP5TDg9WZ4WETDzvNrHQLq0e+w5esrJBC0gHUp3/IlnMC phwVH+xcVbZHRlYkzmMy+kv3ue3oRBP1za7pyDYHvpJf7IkNU1o0XkPYXOhbS8Fl Xk7H02TgGKXKr3SYSq0sxtCvtJLkvexAeO2Ocj7cBBZCV2j211R2gnCr8+IraE5v mqJzp7ZopqLaUnVjXNJlv5NN3c4cla00vXtO4ZHZdP5Tj2zCNtJmt9pudj9WAlxn adfKJJ7p24rMBQ26njB6O/+wBL6G87rjj/lJcRNU19pn5EEp/ybsK0aPTcqidF3f hUhHMDUxIp45sdt11Sff =Nm+j -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AF46E4D8-EA45-4597-926A-E333A8473A15>