[19249] in Kerberos_V5_Development
Re: krb5.conf and 32 vs 64-bit plugins
daemon@ATHENA.MIT.EDU (Tomas Kuthan)
Mon Aug 17 12:13:23 2015
Message-ID: <55D20812.3000103@oracle.com>
Date: Mon, 17 Aug 2015 18:13:06 +0200
From: Tomas Kuthan <tomas.kuthan@oracle.com>
MIME-Version: 1.0
To: Benjamin Kaduk <kaduk@mit.edu>
In-Reply-To: <alpine.GSO.1.10.1508170945430.22210@multics.mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 08/17/15 03:48 PM, Benjamin Kaduk wrote:
> On Mon, 17 Aug 2015, Tomas Kuthan wrote:
>
>> On 08/17/15 06:33 AM, Greg Hudson wrote:
>>> On 08/14/2015 08:43 AM, Tomas Kuthan wrote:
>>>> We would like to solve that by supporting $ISA place holder in the path,
>>>> that would translate to '/64/' on 64-bit and to '/' on 32-bit. Hence the
>>>> following (artificial) example would work fine for both:
>>>>
>>>> module = pkinit:/lib/$ISA/site/preauth/pkinit.so
>>>>
>>>> Would MIT be willing to accept a patch implementing something along
>>>> these lines?
>>>
>>> My concern is that different operating systems have done different
>>> things with 32-bit and 64-bit libraries, even within the space of Linux
>>> distributions. Rather than a solution narrowly tailored to one
>>> operating system, I would like a plan which can cover a broad range of
>>> operating systems, preferrably one which doesn't add a lot of complexity
>>> to the code.
>>>
>>
>> Hi Greg,
>>
>> thank you for your reply.
>>
>> Just to clarify, with this proposal we are trying to address plugins in
>> non-default library path (I should have made up a better example, such
>> as "/opt/vendor/product/version/lib/plugins/$ISA/"). Default library
>> path already works fine for both 32 and 64-bit.
>>
>> How about supporting the following macros, that would be settable at
>> configure with the following default values:
>>
>> #define ISA_STRING "/$ISA/"
>> #define ISA_32 "/"
>> #define ISA_64 "/64/"
>>
>> I believe this should offer enough flexibility.
>
> I'm unconvinced that 32- and 64-bit (x86) are the only ABIs that need to
> be considered. ARM is an interesting case, with thumb-ABI as an option,
> hard- or soft-float (not that we use much floating-point, but it's
> illustrative of the ABI explosion), and other options once you start
> permit running on different chips. It really seems like something more
> generic than 32 vs 64 bits is going to be needed.
>
> -Ben
>
Hi Ben,
I am not familiar with thumb-ABI (basically all I know is that it exists).
So for example if I have an application compiled in thumb instruction
set and I try to dlopen a regular 32-bit ARM plugin, dlopen would fail?
Or can thumb and ARM code co-exist in this way?
Thanks,
Tomas
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
