From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id AE80C385B831 for ; Sun, 5 Apr 2020 14:38:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AE80C385B831 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 251D730130D0 for ; Sun, 5 Apr 2020 16:38:28 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 5309D413CE32; Sun, 5 Apr 2020 16:38:28 +0200 (CEST) Message-ID: Subject: Surprising behavior of suppress_type drop = yes From: Mark Wielaard To: libabigail@sourceware.org Date: Sun, 05 Apr 2020 16:38:28 +0200 Content-Type: multipart/mixed; boundary="=-Fd+1aQPeHoDxdWbsxNvA" X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-22.5 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP 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: Libabigail mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 14:38:33 -0000 --=-Fd+1aQPeHoDxdWbsxNvA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, In my project we have a lot of large private structures that the user can never access directly, they will always be referenced through opaque pointers. And we don't guarantee the data layout of those private data structures. So we suppress them with [suppress_type] source_location_not_in =3D list.h, of.h, public.h, headers.h. Since they are not necessary and they make the xml abi files pretty big we also remove them from the abi files with drop =3D yes. But now we cannot use any opaque handles anymore since any function parameter that uses a pointer to an opaque typedef/structure will also be dropped from the abi. This is highly confusing (at least to me). I had assumed they would just be treated as void pointers instead. As an example of what I had hoped would work consider the foolib project as attached. The initial version uses void pointers. But a new version adds some type safety to the library by replacing the void pointers by opaque Foo pointers. This should be abi compatible, but gives the following surprising abi diff: $ make gcc -fPIC -g -O2 -Wall -Wextra -c -o foo.o foo.c gcc -fPIC -g -O2 -Wall -Wextra -shared foo.o -o libfoo.so $ make libfoo.abi abidw --no-show-locs --no-corpus-path --no-comp-dir-path \ --suppressions libfoo.supp \ --out-file libfoo.abi libfoo.so $ cp libfoo.abi{,.orig} $ patch -p1 < 0001-Add-Foo-handle-to-replace-generic-void.patch $ make gcc -fPIC -g -O2 -Wall -Wextra -c -o foo.o foo.c gcc -fPIC -g -O2 -Wall -Wextra -shared foo.o -o libfoo.so $ make libfoo.abi abidw --no-show-locs --no-corpus-path --no-comp-dir-path \ --suppressions libfoo.supp \ --out-file libfoo.abi libfoo.so $ abidiff --suppressions libfoo.supp libfoo.abi{.orig,} Functions changes summary: 0 Removed, 4 Changed, 0 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable 4 functions with some indirect sub-type change: [C]'function void* create_foo()' has some indirect sub-type changes: return type changed: entity changed from 'void*' to 'void' type size changed from 64 to 0 (in bits) [C]'function void destroy_foo(void*)' has some indirect sub-type changes: parameter 1 of type 'void*' was removed [C]'function int get_foo(void*)' has some indirect sub-type changes: parameter 1 of type 'void*' was removed [C]'function void set_foo(void*, int)' has some indirect sub-type changes= : parameter 1 of type 'void*' changed: entity changed from 'void*' to 'int' type size changed from 64 to 32 (in bits) parameter 2 of type 'int' was removed Note how abidiff treats the function return type and parameters changed from void * to Foo * as disappearing. Is there another way to achieve what I want/need? Or can we have a "drop mode" that treats handles to dropped types a simple void pointers instead? Thanks, Mark P.S. If we leave off the drop =3D yes, but keep the [suppress_type] source_location_not_in =3D foo.h we still get a report on the type change, even though I think it is abi compatible: $ abidiff --suppressions libfoo.supp libfoo.abi{.orig,} Functions changes summary: 0 Removed, 4 Changed, 0 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable 4 functions with some indirect sub-type change: [C]'function void* create_foo()' has some indirect sub-type changes: return type changed: in pointed to type 'void': entity changed from 'void' to 'typedef Foo' type size changed from 0 to 32 (in bits) [C]'function void destroy_foo(void*)' has some indirect sub-type changes: parameter 1 of type 'void*' changed: in pointed to type 'void': entity changed from 'void' to 'typedef Foo' type size changed from 0 to 32 (in bits) [C]'function int get_foo(void*)' has some indirect sub-type changes: parameter 1 of type 'void*' changed: in pointed to type 'void': entity changed from 'void' to 'typedef Foo' type size changed from 0 to 32 (in bits) [C]'function void set_foo(void*, int)' has some indirect sub-type changes= : parameter 1 of type 'void*' changed: in pointed to type 'void': entity changed from 'void' to 'typedef Foo' type size changed from 0 to 32 (in bits) How would I tell abidw/diff that an (opaque) pointer change like that isn't an ABI break? --=-Fd+1aQPeHoDxdWbsxNvA Content-Disposition: inline; filename="foo.c" Content-Type: text/x-csrc; name="foo.c"; charset="UTF-8" Content-Transfer-Encoding: base64 I2luY2x1ZGUgImZvb1AuaCIKI2luY2x1ZGUgPHN0ZGxpYi5oPgoKdm9pZCAqCmNyZWF0ZV9mb28g KHZvaWQpCnsKICByZXR1cm4gbWFsbG9jIChzaXplb2YgKHN0cnVjdCBmb28pKTsKfQoKdm9pZApk ZXN0cm95X2ZvbyAodm9pZCAqZm9vKQp7CiAgZnJlZSAoZm9vKTsKfQoKdm9pZApzZXRfZm9vICh2 b2lkICpmb28sIGludCBudW0pCnsKICBzdHJ1Y3QgZm9vICppbnN0YW5jZSA9IChzdHJ1Y3QgZm9v ICopIGZvbzsKICBpbnN0YW5jZS0+bnVtID0gbnVtOwp9CgppbnQKZ2V0X2ZvbyAodm9pZCAqZm9v KQp7CiAgc3RydWN0IGZvbyAqaW5zdGFuY2UgPSAoc3RydWN0IGZvbyAqKSBmb287CiAgcmV0dXJu IGluc3RhbmNlLT5udW07Cn0K --=-Fd+1aQPeHoDxdWbsxNvA Content-Disposition: attachment; filename="foo.h" Content-Type: text/x-chdr; name="foo.h"; charset="UTF-8" Content-Transfer-Encoding: base64 dm9pZCAqY3JlYXRlX2ZvbyAodm9pZCk7CnZvaWQgZGVzdHJveV9mb28gKHZvaWQgKmZvbyk7CnZv aWQgc2V0X2ZvbyAodm9pZCAqZm9vLCBpbnQgbnVtKTsKaW50ICBnZXRfZm9vICh2b2lkICpmb28p Owo= --=-Fd+1aQPeHoDxdWbsxNvA Content-Disposition: attachment; filename="fooP.h" Content-Type: text/x-chdr; name="fooP.h"; charset="UTF-8" Content-Transfer-Encoding: base64 I2luY2x1ZGUgImZvby5oIgoKc3RydWN0IGZvbwp7CiAgaW50IG51bTsKfTsK --=-Fd+1aQPeHoDxdWbsxNvA Content-Disposition: attachment; filename="libfoo.supp" Content-Type: text/plain; name="libfoo.supp"; charset="UTF-8" Content-Transfer-Encoding: base64 W3N1cHByZXNzX3R5cGVdCiAgc291cmNlX2xvY2F0aW9uX25vdF9pbiA9IGZvby5oCiAgZHJvcCA9 IHllcwo= --=-Fd+1aQPeHoDxdWbsxNvA Content-Disposition: attachment; filename="Makefile" Content-Type: text/x-makefile; name="Makefile"; charset="UTF-8" Content-Transfer-Encoding: base64 U09VUkNFUyA9IGZvby5jCk9CSkVDVFMgPSAkKFNPVVJDRVM6LmM9Lm8pClRBUkdFVCA9IGxpYmZv by5zbwpUQVJHRVRBQkkgPSAkKFRBUkdFVDouc289LmFiaSkKQUJJU1VQUFJFU1NJT04gPSAkKFRB UkdFVEFCSTouYWJpPS5zdXBwKQoKQ0MgPSBnY2MKQ0ZMQUdTID0gLWZQSUMgLWcgLU8yIC1XYWxs IC1XZXh0cmEKTERGTEFHUyA9IC1zaGFyZWQKCmFsbDogJChUQVJHRVQpCgokKFRBUkdFVCk6ICQo T0JKRUNUUykKCSQoQ0MpICQoQ0ZMQUdTKSAkKExERkxBR1MpICQ8IC1vICRACgokKFRBUkdFVEFC SSk6ICQoVEFSR0VUKQoJYWJpZHcgLS1uby1zaG93LWxvY3MgLS1uby1jb3JwdXMtcGF0aCAtLW5v LWNvbXAtZGlyLXBhdGggXAoJICAgICAgLS1zdXBwcmVzc2lvbnMgJChBQklTVVBQUkVTU0lPTikg XAoJICAgICAgLS1vdXQtZmlsZSAkQCAkPAoKY2xlYW46CglybSAtZiAkKE9CSkVDVFMpICQoVEFS R0VUKSAkKFRBUkdFVEFCSSkKCi5QSE9OWTogY2xlYW4K --=-Fd+1aQPeHoDxdWbsxNvA Content-Disposition: attachment; filename="0001-Add-Foo-handle-to-replace-generic-void.patch" Content-Type: text/x-patch; name="0001-Add-Foo-handle-to-replace-generic-void.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 RnJvbSBiZWQxODg4MTg0Y2ZjYjY5YzEzMzI5ODA1OTFmYzJhOWFmMjBkOGRlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXJrIFdpZWxhYXJkIDxtYXJrQGtsb21wLm9yZz4KRGF0ZTog U3VuLCA1IEFwciAyMDIwIDE1OjQ2OjUyICswMjAwClN1YmplY3Q6IFtQQVRDSF0gQWRkIEZvbyBo YW5kbGUgdG8gcmVwbGFjZSBnZW5lcmljIHZvaWQgKgoKLS0tCiBmb28uYyB8IDE2ICsrKysrKyst LS0tLS0tLS0KIGZvby5oIHwgMTAgKysrKysrLS0tLQogMiBmaWxlcyBjaGFuZ2VkLCAxMyBpbnNl cnRpb25zKCspLCAxMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9mb28uYyBiL2Zvby5jCmlu ZGV4IDc0YjYzMTAuLjUwYmE0M2QgMTAwNjQ0Ci0tLSBhL2Zvby5jCisrKyBiL2Zvby5jCkBAIC0x LDI4ICsxLDI2IEBACiAjaW5jbHVkZSAiZm9vUC5oIgogI2luY2x1ZGUgPHN0ZGxpYi5oPgogCi12 b2lkICoKK0ZvbyAqCiBjcmVhdGVfZm9vICh2b2lkKQogewotICByZXR1cm4gbWFsbG9jIChzaXpl b2YgKHN0cnVjdCBmb28pKTsKKyAgcmV0dXJuIChGb28gKikgbWFsbG9jIChzaXplb2YgKHN0cnVj dCBmb28pKTsKIH0KIAogdm9pZAotZGVzdHJveV9mb28gKHZvaWQgKmZvbykKK2Rlc3Ryb3lfZm9v IChGb28gKmZvbykKIHsKICAgZnJlZSAoZm9vKTsKIH0KIAogdm9pZAotc2V0X2ZvbyAodm9pZCAq Zm9vLCBpbnQgbnVtKQorc2V0X2ZvbyAoRm9vICpmb28sIGludCBudW0pCiB7Ci0gIHN0cnVjdCBm b28gKmluc3RhbmNlID0gKHN0cnVjdCBmb28gKikgZm9vOwotICBpbnN0YW5jZS0+bnVtID0gbnVt OworICBmb28tPm51bSA9IG51bTsKIH0KIAogaW50Ci1nZXRfZm9vICh2b2lkICpmb28pCitnZXRf Zm9vIChGb28gKmZvbykKIHsKLSAgc3RydWN0IGZvbyAqaW5zdGFuY2UgPSAoc3RydWN0IGZvbyAq KSBmb287Ci0gIHJldHVybiBpbnN0YW5jZS0+bnVtOworICByZXR1cm4gZm9vLT5udW07CiB9CmRp ZmYgLS1naXQgYS9mb28uaCBiL2Zvby5oCmluZGV4IDY3YTE5N2QuLjBiODAzNTQgMTAwNjQ0Ci0t LSBhL2Zvby5oCisrKyBiL2Zvby5oCkBAIC0xLDQgKzEsNiBAQAotdm9pZCAqY3JlYXRlX2ZvbyAo dm9pZCk7Ci12b2lkIGRlc3Ryb3lfZm9vICh2b2lkICpmb28pOwotdm9pZCBzZXRfZm9vICh2b2lk ICpmb28sIGludCBudW0pOwotaW50ICBnZXRfZm9vICh2b2lkICpmb28pOwordHlwZWRlZiBzdHJ1 Y3QgZm9vIEZvbzsKKworRm9vICpjcmVhdGVfZm9vICh2b2lkKTsKK3ZvaWQgZGVzdHJveV9mb28g KEZvbyAqZm9vKTsKK3ZvaWQgc2V0X2ZvbyAoRm9vICpmb28sIGludCBudW0pOworaW50ICBnZXRf Zm9vIChGb28gKmZvbyk7Ci0tIAoyLjE4LjIKCg== --=-Fd+1aQPeHoDxdWbsxNvA--