From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 4C46E385043C for ; Thu, 25 Feb 2021 13:41:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4C46E385043C Received: by mail-wm1-x330.google.com with SMTP id x16so4660485wmk.3 for ; Thu, 25 Feb 2021 05:41:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qack1IM2t6RhAa/VCJUS8yw2dj7sCJjobWHrxEeqie8=; b=qoeEBWzhH10rJoqA0OKd/qzcqsRWCLUaxSGzhUnH1D9iVCLFvGzlVKI72s7Qnrswot x53DQQ6hKJg9K5xbPd433ZpC/+lLyn0P0DBFkDun6gLg3ClwqT03/HDvys+CU7xhV8tB lKC/9+AnVHcKWnk3g9F18SMkoCIYSnRIkjiRIz9m2dk/VvuKt4JQU2msOmRXYR2QdM8G vTrJOqdE1/q/KriCQY0/ZwQlrDKys93RjXYTdmY8GSdx18bCfzw45QYoFJ6T1SPcFlfy uKbHxuoKCY9KSBxVIH9wEDzHADhqMlnUicPKkrTX/zRkPChzERoua1uZi4u5u5hP43v+ Vn5g== X-Gm-Message-State: AOAM530LkSKmMQ51CS/mmRmvwmlNPdzSKZgOMN5gSh68oi9fSnOCH04I NWI5ekhJgTDlx4nUWQew61KDTQ== X-Google-Smtp-Source: ABdhPJyddJ3FCJ8b4/QU7tkc37zGYd3ijaiBbYwjd/sd/cqJdqlzBzXMBDr5FAgUQTWAlYurD04WAg== X-Received: by 2002:a7b:c922:: with SMTP id h2mr3362193wml.44.1614260479894; Thu, 25 Feb 2021 05:41:19 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:a823:eb11:c0f1:25d9]) by smtp.gmail.com with ESMTPSA id w13sm9717863wre.2.2021.02.25.05.41.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Feb 2021 05:41:17 -0800 (PST) Date: Thu, 25 Feb 2021 13:41:16 +0000 From: Matthias Maennich To: Ketan Patil Cc: "libabigail@sourceware.org" , Sachin Nikam , Nicolin Chen Subject: Re: abidw for non-exported structures Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-22.6 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 13:41:22 -0000 Hi! On Thu, Feb 25, 2021 at 11:25:53AM +0000, Ketan Patil via Libabigail wrote: >Hi, > >I was experimenting with abidw and abidiff tools to check ABI changes in linux kernel. >I had performed few experiments: > > 1. Changing exported structures: > * I changed few structures (added some dummy members in between) which were exported and build the kernel and created abi xml file using abidw tool. > * Then I compared this xml with the baseline xml (kernel without any changes) using abidiff tool and I found that it catches this ABI change. > 2. Changing non-exported structures: > * I changed few non-exported structures e.g. struct dm_ioctl In https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/uapi/linux/dm-ioctl.h?h=v5.10.18 > * This struct is being used by a number of ioctls. So I think, changing this struct should be flagged as an ABI change. > * Then I build the kernel and created the new abi xml file using abidw tool and compared with baseline xml using abidiff tool. > * abidiff tool is not able to catch this. Also, I don't see any entry for dm_ioctl in the xml generated using abidw. > > >Does it mean that, abidw tool does not work for the non exported symbols? If yes, are you planning to add this feature? >Can you please let me know or redirect? libabigail works roughly like this (in its default mode): It reads symbol information from the ELF symbol table and matches symbols with corresponding DWARF information to gather type information associated with it. The type information is recursively resolved to capture nested types. So, fundamentally, to capture and eventually report a structure in the ABI, it needs to be contributing to the definition of an exported symbol. E.g. consider this snippet. | enum my_enum { | VALUE, ANOTHER_VALUE | }; | | struct my_struct { | // some interesting bits | }; | | struct another_struct; | | // consider publicly exported function | int my_function(int my_enum, struct my_struct s1, struct another_struct* s2) { | if (my_enum == VALUE) { | // something | } | } The enum technically participates in the ABI, but this is invisible for libabigail as the type information is not connected. As opposed to my_struct. This is part of the type information of my_function and changes therefore would be discoverable. For the forward declared another_struct, we have again the case that changes to this data structure can't be captured as the type is passed by reference and the details are hidden from the ABI. Not even we know anything further about this struct. If my_function is not exported at all (i.e. not part of the observable ABI), any analysis will ignore it, entirely and rightfully. For the Linux kernel there is an additional fact to consider. In the default way (without using whitelists), symbols are considered part of the ABI (or in this case Kernel Module Interface (KMI)), if they are exported via EXPORT_SYMBOL* macros and therefore part of the ksymtab. If a data structure is not participating in the type information of an exported symbol, changes to it will not be discoverable. In order to discover changes to those, you need to make them discoverable, e.g. by exporting a function that takes 'struct dm_ioctl' as an argument type. Cheers, Matthias > >Thanks, >Ketan Patil >