Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

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

 



Hello,

Nicholas Piggin <npiggin@xxxxxxxxx> a écrit:

[...]

> That said, a dwarf based checker tool should be able to do as good a job
> (maybe a bit better because report is very informative and it may pick up
> compiler alignments or padding options).

So, Nicholas was kind enough to send me the two Linux Kernel binaries
that he built with the tiny little interface change that we were
discussing earlier.  Here is what the abidiff[1] tools says about that
interface change:

    $ time ~/git/libabigail/kabidiff/build/tools/abidiff vmlinux.abi1.abi vmlinux.abi2.abi
    Functions changes summary: 0 Removed, 1 Changed, 0 Added function
    Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

    1 function with some indirect sub-type change:

      [C]'function int foo(blah*)' at memory.c:82:1 has some indirect sub-type changes:
        parameter 1 of type 'blah*' has sub-type changes:
          in pointed to type 'struct blah' at memory.c:78:1:
            type size changed from 32 to 64 bits
            1 data member insertion:
              'int blah::y', at offset 0 (in bits) at memory.c:79:1
            1 data member change:
             'int blah::x' offset changed from 0 to 32 (in bits) (by +32 bits)



    real	0m2.595s
    user	0m2.489s
    sys	0m0.108s
    $ 

I kept the timing information to give you an idea of the time it takes
on a non-optimized build of abidiff.

One could for instance want that types that are not defined in header
files be kept out of the change report.  In that case it's possible to
write a little suppression specification file like this one:

    $ cat vmlinux.abignore 
    [suppress_type]
      source_location_not_regexp = .*\\.h
    $

You can then pass that suppression file to the tool:

    $ ~/git/libabigail/kabidiff/build/tools/abidiff --suppr vmlinux.abignore vmlinux.abi1.abi vmlinux.abi2.abi
    Functions changes summary: 0 Removed, 0 Changed (1 filtered out), 0 Added function
    Variables changes summary: 0 Removed, 0 Changed, 0 Added variable


    real	0m2.574s
    user	0m2.473s
    sys	0m0.102s
    $

So this is the kind of interface change analysis tool we are working on
at the moment.

One could also imagine a tool that would compute a CRC that takes the
very same suppression specification files into account, letting people
to decide that some interface changes are OK.  That CRC would thus be
added to the special ELF sections we already have today.  We could keep
the modversion machinery, but with a greater dose of flexibility.
Whenever modversion detects a change, abidiff would tell people what the
change is exactly.

What do you guys think?

[1]: https://sourceware.org/libabigail/manual/abidiff.html
     Okay, the abidiff I used in this message is one that is not yet
     released.  It's source code is in the dodji/kabidiff branch of the
     Git repository at https://sourceware.org/git/?p=libabigail.git;a=summary


Cheers,

-- 
		Dodji
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux