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

Michal Marek a écrit: >> Libabigail does a "whole binary" analysis of types. >> >> So, consider the point of use of the type 'struct s1*'. Even if 'struct >> s' is just forward-declared at that point, the declaration of struct s1 >> is "resolved" to its definition. Even if

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

Michal Marek a écrit: >> Libabigail does a "whole binary" analysis of types. >> >> So, consider the point of use of the type 'struct s1*'. Even if 'struct >> s' is just forward-declared at that point, the declaration of struct s1 >> is "resolved" to its definition. Even if the definition

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

Dodji Seketeli <do...@seketeli.org> a écrit: Grr, I did paste the wrong content of t1.c and t2.c in my last message sorry. Here are the correct ones: $ cat t1.c struct s1; struct s2 { int i; }; struct s3 { struct s1 *ptr1; struct s2 *ptr2; }; void foo(struct

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

Dodji Seketeli a écrit: Grr, I did paste the wrong content of t1.c and t2.c in my last message sorry. Here are the correct ones: $ cat t1.c struct s1; struct s2 { int i; }; struct s3 { struct s1 *ptr1; struct s2 *ptr2; }; void foo(struct s3* s __attribute__((unused

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

Michal Marek a écrit: [...] > A minimal example would be > > t1.c: > struct s1; > struct s2 { > int i; > } > struct s3 { > struct s1 *ptr1; > struct s2 *ptr2; > } > void foo(struct s3*); > EXPORT_SYMBOL(foo); > > t2.c: > struct s1 { > int j; > } > struct

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

Michal Marek a écrit: [...] > A minimal example would be > > t1.c: > struct s1; > struct s2 { > int i; > } > struct s3 { > struct s1 *ptr1; > struct s2 *ptr2; > } > void foo(struct s3*); > EXPORT_SYMBOL(foo); > > t2.c: > struct s1 { > int j; > } > struct s2; > struct s3

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

Michal Marek a écrit: [...] > Does the abidiff tool handle the case when an exported symbol is moved > between .c files? This is always a mess with genksyms, because the two > .c files have different includes and thus the type expansion stops at > different points. So typically

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

Michal Marek a écrit: [...] > Does the abidiff tool handle the case when an exported symbol is moved > between .c files? This is always a mess with genksyms, because the two > .c files have different includes and thus the type expansion stops at > different points. So typically the move needs

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

Hello, Nicholas Piggin 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

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

Hello, Nicholas Piggin 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

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

Nicholas Piggin a écrit: [...] > On Thu, 1 Dec 2016 11:48:09 +0100 > Stanislav Kozina wrote: > >> On 12/01/2016 05:13 AM, Don Zickus wrote: >> >> ... >> >> > I think GregKH pointed to one such tool, libabigail? We are working on >> > others too. >>

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

Nicholas Piggin a écrit: [...] > On Thu, 1 Dec 2016 11:48:09 +0100 > Stanislav Kozina wrote: > >> On 12/01/2016 05:13 AM, Don Zickus wrote: >> >> ... >> >> > I think GregKH pointed to one such tool, libabigail? We are working on >> > others too. >> >> I should mention one of the others