From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by sourceware.org (Postfix) with ESMTPS id 0EAFB3858D28; Thu, 21 Mar 2024 10:19:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0EAFB3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=seketeli.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0EAFB3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.70.183.199 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711016370; cv=none; b=XgG90Cr+n70DEEkVvOs/NvJcFib8NdG/5c8bf1srzSlYJ+FwE0fKdmOMrbnIM2/b35lvYhmbCogCzcLS1AuOIC8n7b6m/AAjBjAiJOOOlkAY3BE8J/8cAbwyj14v9XTA/q8h7ateRHMvYN+HbpsXI0HMox3sVkcFPuDzICt2vf8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711016370; c=relaxed/simple; bh=cPrk6W9FeCziH4rR1yfkSTm/9cdLgGyjpmqiCg6Duaw=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=UGvqYne6kaXC/VRVOvnsTtrG2xaN8N6uIO/TPnnT5Stn2OUQ9g2eZLyl8p2V/rGCVv7u7kiwweIdiczu/u9vo2lKnXkXvoJ2sgz54fDAl7E6A/2Ih4Pfb1UAFk1yOJ2M2fJXf1HUgb3tmmAFeqxn2oS2QK8RVx0LYVEfXMxrBmw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail.gandi.net (Postfix) with ESMTPSA id 253E9FF804; Thu, 21 Mar 2024 10:19:23 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 662405071022; Thu, 21 Mar 2024 11:19:23 +0100 (CET) From: Dodji Seketeli To: "quic_ashudas at quicinc dot com" Cc: libabigail@sourceware.org, jwakely@redhat.com Subject: Re: [Bug default/31513] abidiff differences due to change in compiler version Organization: Me, myself and I References: X-Operating-System: AlmaLinux 9.3 X-URL: http://www.seketeli.net/~dodji Date: Thu, 21 Mar 2024 11:19:23 +0100 In-Reply-To: (quic ashudas at quicinc dot com's message of "Wed, 20 Mar 2024 10:54:56 +0000") Message-ID: <87edc328gk.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: dodj@seketeli.org X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,FILL_THIS_FORM,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, > Attached the required libraries. Thanks! These have been really useful. So here is my analysis, looking at the debug info. I think it all boils down to a change in the implementation details of the vector type of the standard library. Namely, the type: _Vector_base >::_Vector_impl. Let's look at a dump of the DWARF debuginfo for that type in the binary resulting from the libstdc++ implementation for gcc7.xx: [ 2c03] structure_type abbrev: 17 name (strp) "_Vector_impl" byte_size (data1) 24 decl_file (data1) stl_vector.h (3) decl_line (data1) 81 sibling (ref4) [ 2cc5] [ 2c0f] inheritance abbrev: 59 type (ref4) [ 2540] data_member_location (data1) 0 [ 2c15] member abbrev: 7 name (strp) "_M_start" decl_file (data1) stl_vector.h (3) decl_line (data1) 84 type (ref4) [ 2cc5] data_member_location (data1) 0 [ 2c21] member abbrev: 7 name (strp) "_M_finish" decl_file (data1) stl_vector.h (3) decl_line (data1) 85 type (ref4) [ 2cc5] data_member_location (data1) 8 [ 2c2d] member abbrev: 7 name (strp) "_M_end_of_storage" decl_file (data1) stl_vector.h (3) decl_line (data1) 86 type (ref4) [ 2cc5] data_member_location (data1) 16 [...] So we see that the _Vector_impl type inherits a type identified by the DIE (debug information entry) at offset 0x2540 (which happens to be the type allocator) and has three data members: _M_start, _M_finish, and _M_end_of_storage. Now, let's look at the similar dump of the DWARF debuginfo for that type in the binary resulting from the libstdc++ implementation for gcc11.xx: [ 36b3] structure_type abbrev: 23 name (strp) "_Vector_impl" byte_size (data1) 24 decl_file (data1) stl_vector.h (3) decl_line (data1) 128 decl_column (data1) 14 sibling (ref4) [ 377e] [ 36c0] inheritance abbrev: 50 type (ref4) [ bb5] data_member_location (implicit_const) 0 [ 36c5] inheritance abbrev: 50 type (ref4) [ 35f9] data_member_location (implicit_const) 0 [ 36ca] subprogram abbrev: 24 external (flag_present) yes name (strp) "_Vector_impl" decl_file (data1) stl_vector.h (3) decl_line (data1) 131 decl_column (data1) 2 linkage_name (strp) "_ZNSt12_Vector_baseIcSaIcEE12_Vector_implC4Ev" declaration (flag_present) yes object_pointer (ref4) [ 36de] sibling (ref4) [ 36e4] [ 36de] formal_parameter abbrev: 2 type (ref4) [ 6bce] artificial (flag_present) yes [ 36e4] subprogram abbrev: 24 [...] Here, we see that the _Vector_impl inherits *TWO* types. One is identified by the DIE at offset 0xbb5 (which is the type allocator) and the other is the type identified by the DIE at offset 0x35f9 which the (newly introduced) type: "_Vector_base >::_Vector_impl_data" And we see that this new implementation of _Vector_impl doesn't have any of the data members _M_start, _M_finish, _M_end_of_storage. Now let's look at the DIE for the type: "_Vector_base >::_Vector_impl_data" [ 35f9] structure_type abbrev: 23 name (strp) "_Vector_impl_data" byte_size (data1) 24 decl_file (data1) stl_vector.h (3) decl_line (data1) 91 decl_column (data1) 14 sibling (ref4) [ 36a2] [ 3606] member abbrev: 6 name (strp) "_M_start" decl_file (data1) stl_vector.h (3) decl_line (data1) 93 decl_column (data1) 10 type (ref4) [ 36a7] data_member_location (data1) 0 [ 3613] member abbrev: 6 name (strp) "_M_finish" decl_file (data1) stl_vector.h (3) decl_line (data1) 94 decl_column (data1) 10 type (ref4) [ 36a7] data_member_location (data1) 8 [ 3620] member abbrev: 6 name (strp) "_M_end_of_storage" decl_file (data1) stl_vector.h (3) decl_line (data1) 95 decl_column (data1) 10 type (ref4) [ 36a7] data_member_location (data1) 16 [...] We see that this new type has the three data members _M_start, _M_finish, _M_end_of_storage that are missing from _Vector_impl. In other words, the data members of the class _Vector_impl in gcc7 were moved to the class _Vector_impl_data in gcc11 and _Vector_impl now inherits _V_Vector_impl_data. Note that the layout of the _Vector_impl hasn't changed. Its size hasn't changed either. This is coherent with what abidiff says, when it says that the size hasn't changed (and when it doesn't report any offset change): type of 'std::_Vector_base >::_Vector_impl _M_impl' changed: type size hasn't changed 1 base class insertion: struct std::_Vector_base >::_Vector_impl_data at stl_vector.h:91:1 3 data member deletions: 'std::_Vector_base >::pointer _M_start', at offset 0 (in bits) at stl_vector.h:84:1 'std::_Vector_base >::pointer _M_finish', at offset 64 (in bits) at stl_vector.h:85:1 'std::_Vector_base >::pointer _M_end_of_storage', at offset 128 (in bits) at stl_vector.h:86:1 In other words, this is not an incompatible ABI change. I'd argue that it's not even an ABI change. Now, I am thinking that *maybe* we should make libabigail detect that the data members _M_start, _M_finish and _M_end_of_storage were moved to the new base class _Vector_impl_data with no observable change to the layout of the _Vector_impl class. This would have made the analysis much simpler for the user. What do you think? If you agree, then I think we should add a new enhancement request for that feature. > Ques 1: Is this behavior expected as we have not made any change in the source > files of the library the highlighted changes are in compiler source files. I guess I would answer "it depends". Sorry. This is a real change that happened in the implementation details of the libstdc++ standard library. If, for a reason, you are interested in reviewing this kind of changes you might be interested in *seeing* them in the first place. If, on the other hand, you are not interested in the changes about types (that are implementation details) of the libstdc++ standard library, then yes, these changes should be suppressed from the output of abidiff. You should be able to control this behavior, I think. > Ques 2: If yes, can you share a suppression file to ignore all the > changes which are not from the elf source file. So, here is an example of suppression file that you could use, if you want to suppress all the changes to the types of the "std" namespace: ---------->8<--------------------- [suppress_type] # Suppress changes in types of the std:: namespace name_regexp = ^std::.* --------->8<---------------------- For the record, here is what I am getting when using a suppression file with that content: $ cat default.suppr [suppress_type] # Suppress changes in types of the std:: namespace name_regexp = ^std::.* $ abidiff --suppr default.suppr bin/libloremipsum_gcc7.so bin/libloremipsum_gcc11.so Functions changes summary: 16 Removed, 0 Changed (20 filtered out), 21 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 2 Removed, 2 Added function symbols not referenced by debug info Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info [...] $ Note how all the *type changes* got filtered out, as shown in the summary. I hope this helps. -- Dodji