krb5.conf and 32 vs 64-bit plugins

[Tomas Kuthan]

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