Messages in this thread | | | From | Dodji Seketeli <> | Subject | Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm | Date | Wed, 14 Dec 2016 10:56:56 +0100 |
| |
Dodji Seketeli <dodji@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 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
| |