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 he
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 to
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 {
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
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 comes
5 matches
Mail list logo