From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5369 invoked by alias); 3 Jul 2018 14:59:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 4902 invoked by uid 89); 3 Jul 2018 14:59:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=HX-HELO:sk:mail-wm, Hx-spam-relays-external:74.125.82.68, H*RU:74.125.82.68, behind X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Jul 2018 14:59:21 +0000 Received: by mail-wm0-f68.google.com with SMTP id p11-v6so2623702wmc.4 for ; Tue, 03 Jul 2018 07:59:21 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:75e6:857f:3506:a1f4? ([2001:8a0:f913:f700:75e6:857f:3506:a1f4]) by smtp.gmail.com with ESMTPSA id k16-v6sm1028751wrl.29.2018.07.03.07.59.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 07:59:18 -0700 (PDT) Subject: Re: [PATCH][gdb/testsuite] Fix error message test in dw2-error.exp To: Tom de Vries , gdb-patches@sourceware.org References: <20180619090024.c2yqabvk6oujs6dm@localhost.localdomain> From: Pedro Alves Message-ID: Date: Tue, 03 Jul 2018 14:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180619090024.c2yqabvk6oujs6dm@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-07/txt/msg00053.txt.bz2 On 06/19/2018 10:00 AM, Tom de Vries wrote: > the executable used in dw2-error.exp is compiled from a .s that was generated > with dwarf2 debug information but has been hand-edited to set the version in > the compilation unit header to 0x99: > ... > .Ldebug_info0: > .long 0x4e # Length of Compilation Unit Info > .value 0x99 # DWARF version number > .long .Ldebug_abbrev0 # Offset Into Abbrev. Section > ... > > Consequently, dwarf2read.c:read_comp_unit_head() interprets the compilation > unit header as dwarf5, That right there looks like the real bug to me. I went looking for the history behind the testcase, and got surprised that the testcase is expecting that "wrong unit_type in compilation unit header" error instead of the same error that had been reported in the original bug report at : ~~~~~ Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module ....build/gdb/gdb] ~~~~~ read_and_check_comp_unit_head calls error_check_comp_unit_head after calling read_comp_unit_head, and thus AFAICT error_check_comp_unit_head would error out with the "wrong version" error, the one that had been reported in the original bug report. That seems like a much better error to me. static void error_check_comp_unit_head (struct dwarf2_per_objfile *dwarf2_per_objfile, struct comp_unit_head *header, struct dwarf2_section_info *section, struct dwarf2_section_info *abbrev_section) { const char *filename = get_section_file_name (section); if (header->version < 2 || header->version > 5) error (_("Dwarf Error: wrong version in compilation unit header " "(is %d, should be 2, 3, 4 or 5) [in module %s]"), header->version, filename); So it seems to me that read_comp_unit_head shouldn't be trying to interpret contents of a dwarf version that gdb doesn't understand. Seems like that error_check_comp_unit_head version check is too late? How about moving it into read_and_check_comp_unit_head? Of course, the testcase would then be adjusted to expect the new message, and it would expect 153/0x99 exactly instead of any number, which ensures that gdb reads and prints the version number correctly. Thanks, Pedro Alves > which starts with fields unit_length (4 or 12 byte > unsigned), version (uhalf), and unit_type (ubyte). So, the unit_type > field is initialized from the first byte of .Ldebug_abbrev0 offset. > > Using objdump, we find that the value of that byte is 0x64. > ... > Contents of section .debug_info: > ... > 00c0 00450000 0001804e 00000099 00640000 .E.....N.....d.. > ... > > And indeed gdb errors out accordingly (note: 0x64 == 100): > ... > (gdb) file outputs/gdb.dwarf2/dw2-error/dw2-error > Reading symbols from outputs/gdb.dwarf2/dw2-error/dw2-error... > Dwarf Error: wrong unit_type in compilation unit header > (is 100, should be 1 or 2) > [in module outputs/gdb.dwarf2/dw2-error/dw2-error] > (no debugging symbols found)...done. > ... > > The test fails however because it expects the error message to contain 0 > instead of the 100 we're seeing. > > This patch fixes the failure by allowing any value for the unit_type in the > error message.