Dodji Seketeli <dodji@xxxxxxxxxxxx> 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))) { } $ cat t2.c struct s1 { int j; }; struct s2; struct s3 { struct s1 *ptr1; struct s2 *ptr2; }; void foo(struct s3* s __attribute__((unused))) { } $ gcc -g -c t1.c $ gcc -g -c t2.c $ abidiff t1.o t2.o $ The rest of my previous message still applies :-) > So, as you see here, abidiff considers t1.o and t2.o has having the same > ABI, so it considers the two foo functions to be equivalent. > >> The types are the same, but their visibility in the different >> compilation units differs. > > I see, for genksyms, the order of declarations matters, especially when > forward declarations are involved. > > 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 comes later in > the binary. > > In other words, if struct s1 is defined in the binary, you'll never have > that "struct s1 {UNKNOWN} *ptr1;" that you see in genksyms's > representation. Thanks. -- Dodji -- 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