From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42004 invoked by alias); 17 Mar 2019 16:01:33 -0000 Mailing-List: contact dwz-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: dwz-owner@sourceware.org Received: (qmail 41995 invoked by uid 89); 17 Mar 2019 16:01:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy=consumption, observed, UD:info, states X-Spam-Status: No, score=-25.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: mx1.suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Date: Tue, 01 Jan 2019 00:00:00 -0000 From: Tom de Vries To: dwz@sourceware.org, jakub@redhat.com Subject: [PATCH] Add multifile-low-mem.sh test-case Message-ID: <20190317160215.GA23199@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2019-q1/txt/msg00151.txt.bz2 Jakub, When I run dwz in multifile mode for files 1, 2 and 3 with a low-mem-die-limit low_mem_limit like so: ... $ dwz -l$low_mem_limit -m 4 1 2 3 ... where the low-mem-die-limit triggers for file 3, I observed that file 3 is excluded from wr_multifile mode, but is still included in fi_multifile mode. The documentation in dwz.c states: ... If some executable or shared library has too large debug information (number of DIEs in .debug_info section) that there would be risk of too high memory consumption, that file isn't multifile optimized, instead it is processed by dwz () in a low-memory mode with low_mem flag set. ... My understanding from the documentation is that the behaviour described above is a bug, but I'm not sure, it might be an intended feature. So, my question is: is this a bug? If so, then I can commit the test-case below as is. If not, then I can commit the test-case below modified to accept the [ "$(gnu-debugaltlink-name.sh 3)" = "4" ] case as expected behaviour and close PR24274 as resolved-invalid. Thanks, - Tom Add multifile-low-mem.sh test-case Add test-case that tests behaviour of dwz in multifile mode for files that trigger the low-mem-die-limit. 2019-03-17 Tom de Vries * testsuite/dwz.tests/multifile-low-mem.sh: New test. --- testsuite/dwz.tests/multifile-low-mem.sh | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/testsuite/dwz.tests/multifile-low-mem.sh b/testsuite/dwz.tests/multifile-low-mem.sh new file mode 100644 index 0000000..51345be --- /dev/null +++ b/testsuite/dwz.tests/multifile-low-mem.sh @@ -0,0 +1,25 @@ +cp ../hello 1 +cp ../hello 2 +cp ../dwz-for-test 3 + +low_mem_limit=$(readelf -w 3 \ + | grep '(DW_TAG' \ + | wc -l) +low_mem_limit=$((low_mem_limit - 1)) + +dwz -l$low_mem_limit -m 4 1 2 3 + +smaller-than.sh 1 ../hello +smaller-than.sh 2 ../hello +smaller-than.sh 3 ../dwz-for-test + +[ $(gnu-debugaltlink-name.sh 1) = "4" ] +[ $(gnu-debugaltlink-name.sh 2) = "4" ] + +if [ "$(gnu-debugaltlink-name.sh 3)" = "4" ]; then + echo "PR24274 workaround used" > dwz.info +else + [ "$(gnu-debugaltlink-name.sh 3)" = "" ] +fi + +rm -f 1 2 3 4