lkml.org 
[lkml]   [2016]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
Date
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

\
 
 \ /
  Last update: 2016-12-14 10:57    [W:0.187 / U:1.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site