libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Better soname linking


From: Jan Engelhardt
Subject: Re: Better soname linking
Date: Wed, 4 Nov 2009 22:08:38 +0100 (CET)
User-agent: Alpine 2.00 (LSU 1167 2008-08-23)

On Wednesday 2009-11-04 20:49, Ralf Wildenhues wrote:
>* Jan Engelhardt wrote on Wed, Nov 04, 2009 at 08:42:00PM CET:
>> What if a symbol has kept its name, yet changed in semantics?
>> The Linux Kernel has a number of features that address these
>> issues for itself,
>
>Can you expand on this, please?  Pointers sufficient.

As far I understand it, a symbol's ABI (that is, a binary blob that 
describes that) will be CRC32-checksummed and this checksum be recorded. 
In current practice, it is implemented as fake symbols in one of the 
intermediate output files that you can nm, and somewhat different 
(different section nm does not care about?) in the final image:

        $ nm vmlinux | grep __crc_
        00000000881039d0 A __crc_zlib_inflate
                ^ there's your CRC

The same checksums are computed for calls the module makes.

$ modprobe --dump-modversions btrfs.ko|grep zlib
0x881039d0      zlib_inflate

Checksums are compared on loading a module and can be rejected if they 
do not match -- or if they are simply not found.
Details of that should be in $linux/scripts/modversion.c or accompanying 
.c files. I did not find all of it offhand.

Since the CRCs can be obtained at all, they _are_ actually used for 
kernel rpm packages in openSUSE, with success. Especially when the ABI 
does not change (minor updates such as 2.6.31 -> 2.6.31.5), things like 
nvidia.ko can hang around unmodified for quite a while when it does not 
use frequently-changing APIs. (Which btw is a side-effect of the legal 
yadayada, not really an effort to avoid CRC mismatches).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]