On 2016-12-14 09:58, Dodji Seketeli wrote: > Michal Marek <mmarek@xxxxxxxx> 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 to be reverted as a >> workaround. > > Let's consider the function: > > 'void foo(struct S*);' > > If two ELF binaries contain a definition of that function foo which ELF > symbol is exported, if the type struct S hasn't changed, and if the only > difference between the ELF binaries is that foo was defined in the > translation unit a.c in the first binary and in b.c in the second > binary, then the comparison engine of libabigail (which is the library > that abidiff uses) will consider the declarations of the two foo > functions as being equal -- no matter what include file comes before the > definition point of foo in a.c and b.c. If it does not, then it's a bug > that ought to be fixed. > > If you feel that I haven't understood your question, then I guess a > minimal standalone example (in the form of C source code) that > illustrates your use case could be helpful to me. 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 { struct s1 *ptr1; struct s2 *ptr2; } void foo(struct s3*); EXPORT_SYMBOL(foo); genksyms expands this to void foo ( struct s3 { struct s1 { UNKNOWN } * ptr1 ; struct s2 { int i ; } * ptr2 ; } * ) or void foo ( struct s3 { struct s1 { int j ; } * ptr1 ; struct s2 { UNKNOWN } * ptr2 ; } * ) respectively. The types are the same, but their visibility in the different compilation units differs. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html